[Openswan Users] Connection to checkpoint FT NG: ip alias using netkey SOLVED !!! (plain text message)

Fri Oct 3 11:00:55 EDT 2014

SOLVED!!!!

THANKS NICK!!!!

so the solution was:

1) No need to use ip alias
2) use in the config he fake ip address as leftsourceip and also as subnet/32
3) place the postroute rule in iptables

For future reference, this is the working setup:

*** TOPOLOGY ***

client (dhcp ip 192.168.100.100)
|
|
ADSL GW/NAT(public ip unknown)
|
|
(INTERNET)
|
|
CP FIREWALL (public ip Y.Z.W.T)
|
|
two subnets (192.168.2.0/24 192.168.3.0/24)

*** CONFIG ***

# /etc/ipsec.conf - Openswan IPsec configuration file
version    2.0    # conforms to second version of ipsec.conf specification
config setup
    dumpdir=/var/run/pluto/
    nat_traversal=yes
    virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:25.0.0.0/8,%v6:fd00::/8,%v6:fe80::/10
    oe=off
    protostack=netkey # I set this to avoid warning message at connection startup
conn roadwarrior
        left=%defaultroute
        leftsubnet=192.168.1.11/32 # faked client IP (the one that is known to CP fw), I need to set it because I'm using also a "rightsubnets" list
        leftcert=my_crt.pem
        leftrsasigkey=%cert
        leftid=%fromcert
        leftsourceip=192.168.1.11 # faked client IP (the one that is known to CP fw)
        #
        right=X.Y.W.Z
        rightsubnets={ 192.168.2.0/24 192.168.3.0/24 }
        rightcert=fw_crt.pem
        rightrsasigkey=%cert
        rightid=X.Y.W.Z
        #
        auto=start
*** IPTABLES ***

iptables -t nat -I POSTROUTING -d 192.168.2.0/24 -j SNAT --to 192.168.1.11 # faked client IP (the one that is known to CP fw)
iptables -t nat -I POSTROUTING -d 192.168.3.0/24 -j SNAT --to 192.168.1.11 # faked client IP (the one that is known to CP fw)

Thanks again Nick!!!!

P.S.: My silly mail client insists on using HTML format, I post it again in plain text to avoid scrubbing...

Sent: Friday, October 03, 2014 at 4:38 PM
From: "Nick Howitt" <nick at howitts.co.uk>
To: "Luca Arzeni" <l.arzeni at iname.com>
Cc: users <users at lists.openswan.org>
Subject: Re: [Openswan Users] Connection to checkpoint FT NG: ip alias using netkey

That looks like your tunnel is working.

Have you changed leftsubnet back to 192.168.1.11/32?

On 03/10/2014 15:34, Luca Arzeni wrote:

Alas,
this is the only think on which I can rest assured!

Oct  3 16:31:06 magdala pluto[16575]: "roadwarrior/0x1" #2: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2
Oct  3 16:31:06 magdala pluto[16575]: "roadwarrior/0x1" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0x022c3823 <0xcf2e9985 xfrm=3DES_0-HMAC_SHA1 NATOA=none NATD=none DPD=none}

I think that the checkpoint expects my packets coming from 192.168.1.11, but instead it receives them from 192.168.100.100 and so drops them...

:-(

Ideas?

Thanks, Luca

Sent: Friday, October 03, 2014 at 4:18 PM
From: "Nick Howitt" <nick at howitts.co.uk>[nick at howitts.co.uk]
To: "Luca Arzeni" <l.arzeni at iname.com>[l.arzeni at iname.com]
Cc: users <users at lists.openswan.org>[users at lists.openswan.org]
Subject: Re: [Openswan Users] Connection to checkpoint FT NG: ip alias using netkey

You need to SNAT traffic from 192.168.100.100 to 192.168.1.11 so my rule was correct. You don't appear to be using your original ipsec.conf where leftsubnet was set to 192.168.1.11/32. With your current set up I doubt that you have an IPsec VPN established. Check your /var/log/messages for an "IPsec SA established" message to see if you have a tunnel established.

On 03/10/2014 15:01, Luca Arzeni wrote:

Sorry Nick, but may be I did a mistake:
you wrote:

iptables -t nat -I POSTROUTING -d 192.168.2.0/23 -j SNAT --to
192.168.1.11

That is: place as --to the SNAT the leftsourceip
=> If I do this I get a: no route to host message!

I've also tested with:
iptables -t nat -I POSTROUTING -d 192.168.2.0/23 -j SNAT --to
192.168.100.100

That is: place as --to the SNAT my real ip, 
=> and this way I've got a timeout message on ssh.

Just to recap, my current config is:
==========
config setup
    dumpdir=/var/run/pluto/
    nat_traversal=yes
    virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:25.0.0.0/8,%v6:fd00::/8,%v6:fe80::/10
    oe=off
    protostack=netkey # I set this to avoid warning message at connection startup
conn roadwarrior
        left=%defaultroute
        leftsubnet=192.168.100.100/32 # client IP, I need to set it because I'm using also a "rightsubnets" list
        leftcert=my_crt.pem
        leftrsasigkey=%cert
        leftid=%fromcert
        leftsourceip=192.168.1.11
        #
        right=Y.Z.W.T
        rightsubnets={ 192.168.2.0/24  192.168.3.0/24 }
        rightcert=fw_crt.pem
        rightrsasigkey=%cert
        rightid=Y.Z.W.T
        #
        auto=start
=========
Then: 

With NO rule in nat table
=> I've got a: "No route to host" message

With rule:
iptables -t nat -I POSTROUTING -d 192.168.2.0/23 -j SNAT --to
192.168.1.11
=> I've got: "No route to host" message

With rule:
iptables -t nat -I POSTROUTING -d 192.168.2.0/23 -j SNAT --to
192.168.100.100
=>  I've got: "Connection timed out" message

The behaviour is the same if I set 192.168.1.11 (leftsourceip) as alias to my eth0 and even if I don't set it.

I've no other idea!

I'm wandering if this is a limit of my openswan release (2.6.37-3+deb7u1) and if, in future revision it could work...
What do you think?

Thanks,
Luca

Sent: Friday, October 03, 2014 at 3:45 PM
From: "Nick Howitt" <nick at howitts.co.uk>
To: "Luca Arzeni" <l.arzeni at iname.com>
Cc: users <users at lists.openswan.org>
Subject: Re: [Openswan Users] Connection to checkpoint FT NG: ip alias using netkey

Try un-setting the alias. I don't think it is necessary but I have no more ideas.
Nick

On 03/10/2014 14:31, Luca Arzeni wrote:

No way:Connection timed out

/sbin/iptables -L -n -t nat 
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            policy match dir out pol ipsec
SNAT       all  --  0.0.0.0/0            192.168.3.0/24      to:192.168.1.11

I'm wandering if the problem is caused by the ip alias, which is out of my 192.168.100.0/24 network...

What do toy think?

Sent: Friday, October 03, 2014 at 3:20 PM
From: "Nick Howitt" <nick at howitts.co.uk>
To: "Luca Arzeni" <l.arzeni at iname.com>
Cc: users <users at lists.openswan.org>
Subject: Re: [Openswan Users] Connection to checkpoint FT NG: ip alias using netkey

What firewall rules do you have. If your connection is being established presumably you are allowing incoming UDP:4500 in your roadwarrior. Do you also have a rule to allow traffic into the tunnel? There are lots of different variants I've seen but this generic one should work:iptables -t nat -I POSTROUTING -m policy --dir out --pol ipsec -j ACCEPTNick

On 03/10/2014 14:02, Luca Arzeni wrote:

Hi Nick,
I've tried but I've got a timeout:
ssh 192.168.3.10
ssh: connect to host 192.168.3.10 port 22: Connection timed out

Is it the firewall is discarding my packets?
Any hint?

Thanks,
Luca

Sent: Monday, September 29, 2014 at 2:12 PM
From: "Nick Howitt" <nick at howitts.co.uk>
To: "Luca Arzeni" <l.arzeni at iname.com>
Cc: users <users at lists.openswan.org>
Subject: Re: [Openswan Users] Connection to checkpoint FT NG: ip alias using netkey
Does it work if you use your initial configuration then, in your client
at home, add a firewall rule:

iptables -t nat -I POSTROUTING -d 192.168.2.0/23 -j SNAT --to
192.168.1.11

You can get more selective with the firewall rule if you need to.

Nick

On 2014-09-29 10:29, Luca Arzeni wrote:
> Hi,
> (it seems that my previous request was unreadable, so here is a plain
> text one... I apologize...)
> I'm trying to setup a connection form a linux roadwarrior to
> checkpoint ng Firewall
> client environment: debian wheezy 7.6 amd64, openswan 2.6.37-3+deb7u1,
> kernel 3.2.60-1+deb7u3 x86_64, NETKEY
>
> Topology:
>
> client (dhcp ip 192.168.1.11)
> |
> |
> ADSL GW/NAT(public ip unknown)
> |
> |
> (INTERNET)
> |
> |
> CP FIREWALL (public ip Y.Z.W.T)
> |
> |
> two subnets (192.168.2.0/24 192.168.3.0/24)
>
> The connection works fine using this setup:
>
> # /etc/ipsec.conf - Openswan IPsec configuration file
> version 2.0 # conforms to second version of ipsec.conf specification
> config setup
> dumpdir=/var/run/pluto/
> nat_traversal=yes
> virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:25.0.0.0/8,%v6:fd00::/8,%v6:fe80::/10
> oe=off
> protostack=netkey # I set this to avoid warning message at connection
> startup
>
> conn roadwarrior
> left=%defaultroute
> leftsubnet=192.168.1.11/32 # client IP, I need to set it because I'm
> using also a "rightsubnets" list
> leftcert=client_crt.pem
> leftrsasigkey=%cert
> leftid=%fromcert
> #
> right=Y.Z.W.T
> rightsubnets={ 192.168.2.0/24 192.168.3.0/24 }
> rightcert=firewall_cert.pem
> rightrsasigkey=%cert
> rightid=Y.Z.W.T
> #
> auto=start
>
> PROBLEM: This setup works fine until I use client IP 192.168.1.11,
> which is registered and well known by checkpoint firewall as a valid
> client IP address.
> BUT when I go home, my client gets a different ip (let's say
> 192.168.100.100), since at home I'm using a different subnet (to allow
> connections also to my office).
>
> Now, in my understanding, checkpoint has found a workaround to solve
> this issue.
> Usually, under windows, roadwarrior clients connect to the CP
> firewalls using a dedicated software made by Checkpoint developers.
> This software creates a virtual network interface, assigns to this
> interface the well known client ip (192.168.1.11) and route all
> traffic through this interface.
> I've tested this software at my home and it works fine.
>
> I would like to mimic this behaviour under linux, so I set an ip alias
> to my eth0; now my eth0 will have 192.168.100.100 (assigned by DHCP
> server) AND 192.168.1.11 which I set manually on the interface, BUT I
> found no working configuration for openswan.
>
>
> Then I've done the following tests:
>
>
> 1) set leftsubnet using the home network ip, i.e.:
> leftsubnet=192.168.100.100/32 (%defaultroute will automagically set to
> 192.168.100.100)
> Connection seems to be OK, I can read in the logs the following
> message:
> STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode
> {ESP=>0x20906a71 <0x22c34963 xfrm=3DES_0-HMAC_SHA1 NATOA=none
> NATD=none DPD=none}
> *** BUT *** ip route list shows that there is no route to servers
>
> 2) then I've add leftsourceip=192.168.1.11
> Connection seems to be OK, I can read in the logs the following
> message:
> STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode
> {ESP=>0xcd521b9a <0xc6eb8d94 xfrm=3DES_0-HMAC_SHA1 NATOA=none
> NATD=none DPD=none}
> ip route list shows that now the routes are available:
> 192.168.3.0/24 dev eth0 scope link src 192.168.1.11
> *** BUT *** if I try to connect to a server, I receive the message:
>> ssh 192.168.3.10
>> ssh: connect to host 192.168.3.10 port 22: No route to host
>
> 3) use leftsubnet=192.168.1.11/32 (that is the office subnet)
> Connection cannot be established, in the logs I can see:
> "roadwarrior/0x6" #1: ignoring informational payload, type
> INVALID_ID_INFORMATION msgid=00000000
> "roadwarrior/0x6" #1: received and ignored informational message
> This is NOT working at all.
>
> 4) set leftsubnets={ 192.168.1.11/32 192.168.100.100/32}
> at start I receive, after the usual message: "ipsec_setup: multiple ip
> addresses, using 192.168.100.100 on eth0"
> the followin (more promising!) message: "ipsec_setup: defaulting
> leftsubnet to 192.168.1.11"
> *** BUT *** in the logs, I see:
> "roadwarrior/2x6" #1: ignoring informational payload, type
> INVALID_ID_INFORMATION msgid=00000000
> "roadwarrior/2x6" #1: received and ignored informational message
> "roadwarrior/1x2" #3: transition from state STATE_QUICK_I1 to state
> STATE_QUICK_I2
> "roadwarrior/1x2" #3: STATE_QUICK_I2: sent QI2, IPsec SA established
> tunnel mode {ESP=>0xfcb61ef1 <0x228bfdf9 xfrm=3DES_0-HMAC_SHA1
> NATOA=none NATD=none DPD=none}
> so it looks like that really only the first subnet is working, and
> still I have "no route to host message" when I try to connect.
>
> === CONCLUSION ===
>
> I guess that the 2 configuration is the right one, but I'm missing
> something...
> Can someone help me?
>
> Thanks,
> larzeni
> _______________________________________________
> Users at lists.openswan.org
> https://lists.openswan.org/mailman/listinfo/users[https://lists.openswan.org/mailman/listinfo/users]
> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy[https://flattr.com/thing/38387/IPsec-for-Linux-made-easy]
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155[http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155]