IpSec / secpol.msc - problems, problems. problems. - Network

This is a discussion on IpSec / secpol.msc - problems, problems. problems. - Network ; Hi folks, after having wasted days of time to get a fairly primitive setup working, I am so desperate that I dare to bug the experts for help.. The scenario is as follows: I want to establish a Ipsec tunnel ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: IpSec / secpol.msc - problems, problems. problems.

  1. IpSec / secpol.msc - problems, problems. problems.

    Hi folks,

    after having wasted days of time to get a fairly primitive setup
    working, I am so desperate that I dare to bug the experts for help..

    The scenario is as follows:

    I want to establish a Ipsec tunnel to a corporate firewall from a
    Windows XP SP-2 computer. I failed for days now. To narrow the problems
    down I have tried to make my test bed as simple as I can. I ended up
    having exactly the same firewall brand, model and firmware, and a laptop
    connected an the wan port (Laptop wan) as well as another one connected
    to the lan port (Laptop LAN).

    The IP settings are as follows:

    Firewall
    WAN Port: 1.12.63.1/255.255.255.0
    LAN Port: 192.168.1.1/255.255.255.0

    Laptop LAN
    IP: 192.168.1.2/255.255.255.0
    Std. Gateway: 192.168.1.1/255.255.255.0

    Laptop WAN
    IP: 1.12.63.2/255.255.255.0
    Std. Gateway: 1.12.63.1

    Both XP laptop's firewalls are down.

    At this point I can PING from Laptop LAN to Laptop WAN, but not reverse.
    this tells me that the cabeling is OK, and that the firewalls stateful
    inspection is working OK. I also loosened the firewalls WAN filters so I
    could successfully establish a http connection to 1.12.63.1 (remote
    management console). then I set the WAN filters to drop anything, and
    log the drops. I want to know what is coming in through the WAN port,
    and I do already know from firewall-firewall VPNs that VPN definitions
    do automatically create a rule that lets incoming tunnel connections
    pass. If this did not work I would at least expect failed connections to
    port 500 in the firewalls event log.

    Now I do intentionally delete the Laptop WAN gateway Ip address. The
    laptop does share a common IP subnet 1.12.63 with the intended tunnel
    endpoint, so there is no need for IP routing to establish a VPN session.
    (Btw, leaving the gateway in place and pinging shows that the firewall
    drops plain ICMP packets at the WAN port, which enforces my assumption
    that the XP client does not even try to establish an encrypred connection).

    Next thing is to enter the VPN configuration in the Firewall. I have
    successfully established tunnels between firewalls of this type and
    brand, so I am quite familiar with the firewall's settings, I don't
    think the problem is here: I also know that the firewall does log
    *something* if a VPN/IPsec connection is not established because of any
    misconfigs. In my case I do not get any log entries on the firewall, so
    I assume that the Laptop WAN does not even try to estabish a connection.
    This shifts attention to the IpSec config of Laptop WAN. To make things
    as easy as I could I choose a very basic security setup for the firewall
    VPN definition: IKE Phase 1 and 2 both SHA1+DES, pre-shared key
    authentication with a password

    I used secpol.msc on Laptop WAN and did the following:

    Step 1: Created a new IP filter with the following settings:

    Source:
    Target: IP subnet: 192.168.1.0/255.255.255.0
    Protocol: any

    Step 2: Created a new IP filter action with the following settings:

    Common options:

    Ip Security:
    ESP settings: SHA1+DES, rekey after 3600 secs. (Same settings as in
    firewall)

    Step 3: Created a new IPsec policy

    Created a new IPSec security rule:
    Tunnel endpoint: 1.12.63.1
    Type: RAS (tried LAN/All connections as well - no change ....)
    Use pre-shared key: (same as in Firewall VPN setup)
    Choose the filter created in step 1
    Choose the filter action created in step 2

    Now I get my new connection listed in secpol.msc, and choose
    properties-apply. Waited a minute or so, rebooted, prayed to the lord
    and then pinged 192.168.1.1.

    Expected behaviour:

    Ping displays "negotiating IPsec ...." several times
    Ping succeeds

    - or -

    I get errors of some kind either on the Laptop WLAN, or in the firewall
    log. Instead nothing happens. The pings fail - and the IPSec
    "negotiating security" text I usually see if I try to PING over an
    encrypted connection does not appear. I therefore assume that the client
    does not know what I want it to do: connect to 1.12.63.1 via IPsec.

    Do I have missed something somewhere ...?

    ....Armin




  2. Re: IpSec / secpol.msc - problems, problems. problems.

    Nimral napisał(a):
    > Hi folks,
    >
    > after having wasted days of time to get a fairly primitive setup
    > working, I am so desperate that I dare to bug the experts for help..
    >
    > The scenario is as follows:
    >
    > I want to establish a Ipsec tunnel to a corporate firewall from a
    > Windows XP SP-2 computer. I failed for days now. To narrow the problems
    > down I have tried to make my test bed as simple as I can. I ended up
    > having exactly the same firewall brand, model and firmware, and a laptop
    > connected an the wan port (Laptop wan) as well as another one connected
    > to the lan port (Laptop LAN).
    >
    > The IP settings are as follows:
    >
    > Firewall
    > WAN Port: 1.12.63.1/255.255.255.0
    > LAN Port: 192.168.1.1/255.255.255.0
    >
    > Laptop LAN
    > IP: 192.168.1.2/255.255.255.0
    > Std. Gateway: 192.168.1.1/255.255.255.0
    >
    > Laptop WAN
    > IP: 1.12.63.2/255.255.255.0
    > Std. Gateway: 1.12.63.1
    >
    > Both XP laptop's firewalls are down.
    >
    > At this point I can PING from Laptop LAN to Laptop WAN, but not reverse.
    > this tells me that the cabeling is OK, and that the firewalls stateful
    > inspection is working OK. I also loosened the firewalls WAN filters so I
    > could successfully establish a http connection to 1.12.63.1 (remote
    > management console). then I set the WAN filters to drop anything, and
    > log the drops. I want to know what is coming in through the WAN port,
    > and I do already know from firewall-firewall VPNs that VPN definitions
    > do automatically create a rule that lets incoming tunnel connections
    > pass. If this did not work I would at least expect failed connections to
    > port 500 in the firewalls event log.
    >
    > Now I do intentionally delete the Laptop WAN gateway Ip address. The
    > laptop does share a common IP subnet 1.12.63 with the intended tunnel
    > endpoint, so there is no need for IP routing to establish a VPN session.
    > (Btw, leaving the gateway in place and pinging shows that the firewall
    > drops plain ICMP packets at the WAN port, which enforces my assumption
    > that the XP client does not even try to establish an encrypred connection).
    >
    > Next thing is to enter the VPN configuration in the Firewall. I have
    > successfully established tunnels between firewalls of this type and
    > brand, so I am quite familiar with the firewall's settings, I don't
    > think the problem is here: I also know that the firewall does log
    > *something* if a VPN/IPsec connection is not established because of any
    > misconfigs. In my case I do not get any log entries on the firewall, so
    > I assume that the Laptop WAN does not even try to estabish a connection.
    > This shifts attention to the IpSec config of Laptop WAN. To make things
    > as easy as I could I choose a very basic security setup for the firewall
    > VPN definition: IKE Phase 1 and 2 both SHA1+DES, pre-shared key
    > authentication with a password
    >
    > I used secpol.msc on Laptop WAN and did the following:
    >
    > Step 1: Created a new IP filter with the following settings:
    >
    > Source:
    > Target: IP subnet: 192.168.1.0/255.255.255.0
    > Protocol: any
    >
    > Step 2: Created a new IP filter action with the following settings:
    >
    > Common options:
    >
    > Ip Security:
    > ESP settings: SHA1+DES, rekey after 3600 secs. (Same settings as in
    > firewall)
    >
    > Step 3: Created a new IPsec policy
    >
    > Created a new IPSec security rule:
    > Tunnel endpoint: 1.12.63.1
    > Type: RAS (tried LAN/All connections as well - no change ....)
    > Use pre-shared key: (same as in Firewall VPN setup)
    > Choose the filter created in step 1
    > Choose the filter action created in step 2
    >
    > Now I get my new connection listed in secpol.msc, and choose
    > properties-apply. Waited a minute or so, rebooted, prayed to the lord
    > and then pinged 192.168.1.1.
    >
    > Expected behaviour:
    >
    > Ping displays "negotiating IPsec ...." several times
    > Ping succeeds
    >
    > - or -
    >
    > I get errors of some kind either on the Laptop WLAN, or in the firewall
    > log. Instead nothing happens. The pings fail - and the IPSec
    > "negotiating security" text I usually see if I try to PING over an
    > encrypted connection does not appear. I therefore assume that the client
    > does not know what I want it to do: connect to 1.12.63.1 via IPsec.
    >
    > Do I have missed something somewhere ...?
    >
    > ...Armin
    >
    >
    >

    Hi
    Everything is ok but in secpol.msc you must configure two
    rules in one IPSec policy:
    One policy - it is the same as you

    "Created a new IPSec security rule:
    > Tunnel endpoint: 1.12.63.1
    > Type: RAS (tried LAN/All connections as well - no change

    .....)
    > Use pre-shared key: (same as in Firewall VPN

    setup)
    > Choose the filter created in step 1
    > Choose the filter action created in step 2"


    an two to reverse comunication:

    > Tunnel endpoint: 1.12.63.2
    > Type: RAS
    > Use pre-shared key: (same as in Firewall VPN

    setup)
    > Choose the filter created in step 1
    > Choose the filter action created in step 2"


    Then everything must be ok.

    ps. you must too in filter list define destination IP and
    source IP and this connection must be mirrored.

    kerma

+ Reply to Thread