[strongSwan] Packets not being encapsulated
Alexis Salinas
alexis.salinas at inmotiontechnology.com
Wed Mar 23 18:35:44 CET 2011
Hi Russ,
I noticed you are using 'forceencaps=yes', so I think your traffic will not be ESP but UDP port 4500.
Do you see any of those packets?+
Cheers,
Alexis
From: users-bounces+alexis.salinas=inmotiontechnology.com at lists.strongswan.org [mailto:users-bounces+alexis.salinas=inmotiontechnology.com at lists.strongswan.org] On Behalf Of Russ Cox
Sent: 23-Mar-11 09:52
To: Andreas Steffen
Cc: users at lists.strongswan.org
Subject: Re: [strongSwan] Packets not being encapsulated
Hi Andreas,
Thanks for the quick reply!
I don't block anything at all outbound on either machine, plus the OUTPUT chain on both is set to ACCEPT
I'm not 100% sure I've answered your question - shout back if you need any more info
Cheers
Russ
iptables -nvL
...
...
Chain OUTPUT (policy ACCEPT 2137K packets, 16G bytes)
pkts bytes target prot opt in out source destination
...
-------------------------
rodney:~# iptables -nvL |grep 192.168.6
0 0 ACCEPT all -- eth2:8 * 192.168.6.0/24 192.168.0.0/24 policy match dir in pol ipsec reqid 16601 proto 50
0 0 ACCEPT all -- * eth2:8 192.168.0.0/24 192.168.6.0/24 policy match dir out pol ipsec reqid 16601 proto 50
--------------------------
root at granville:~# iptables -nvL |grep 192.168.0
0 0 ACCEPT all -- eth1 * 192.168.0.0/24 192.168.6.0/24 policy match dir in pol ipsec reqid 16385 proto 50
7607 647K ACCEPT all -- * eth1 192.168.6.0/24 192.168.0.0/24 policy match dir out pol ipsec reqid 16385 proto 50
On 23 March 2011 16:29, Andreas Steffen <andreas.steffen at strongswan.org> wrote:
Hello Russ,
what about the IPsec policy based firewall rules inserted with
firewall=yes. Do you get any hits on the outbound rules?
Regards
Andreas
On 03/23/2011 04:36 PM, Russ Cox wrote:
> Hi All,
>
> I'm having a bit of a strange issue with a net-net vpn setup where
> packets bound for the remote subnet don't appear to be getting
> encapsulated on either gateway, I see no ESP packets other than those
> attributed with existing functional tunnels.
>
> I've tried tcpdumping on both endpoints, and can see icmp packets coming
> in to the local gateway from hosts on both networks, but no ESP packets
> - and none of it seems to get across the tunnel.
>
> Any help would be greatly appreciated - I've tried doing the same thing
> with IKEV2 (with a couple of required changes) and had exactly the same
> result.
>
> Give me a shout if I can provide any additional information.
>
> Thanks!
>
> Russ
>
> ---------------------
>
> Here's my setup
>
> Rodney:
> Debian lenny x86_64
> Strongswan 4.2.4-5 - from repo
> A number of existing working ikev1 tunnels set up to other networks/hosts
>
> Granville:
> Debian Squeeze x86_64
> Strongswan 4.4.1-5.1 - from repo
>
> Iptables on both hosts:
> udp 500 and 4500 + esp open
>
>
> 192.168.0.0/24-----RODNEY----BRIGHTON_PUB_IP.........ESSEX_PUB_IP---NAT_ROUTER----GRANVILLE----192.168.6.0/24
> <http://192.168.0.0/24-----RODNEY----BRIGHTON_PUB_IP.........ESSEX_PUB_IP---NAT_ROUTER----GRANVILLE----192.168.6.0/24>
>
>
> Essex router nats absolutely everything to Granville (it's on the
> netgear router's dmz)
> --------------------------------------
> ESSEX - IPSEC.CONF
>
> config setup
> plutodebug=control
> nat_traversal=yes
> charonstart=no
> plutostart=yes
>
> conn essex_brighton
> left=%defaultroute
> leftid=ESSEX_PUB_IP
> leftsubnet=192.168.6.0/24 <http://192.168.6.0/24>
> leftfirewall=yes
> right=BRIGHTON_PUB_IP
> rightsubnet=192.168.0.0/24 <http://192.168.0.0/24>
> forceencaps=yes
> keyexchange=ikev1
> authby=secret
> auto=add
> --------------------------------------
>
> BRIGHTON-IPSEC.CONF
>
> config setup
> plutodebug=control
> nat_traversal=yes
> charonstart=yes
> plutostart=yes
>
> conn essex_brighton
> left=BRIGHTON_PUB_IP
> leftsubnet=192.168.0.0/24 <http://192.168.0.0/24>
> leftfirewall=yes
> right=ESSEX_PUB_IP
> rightsubnet=192.168.6.0/24 <http://192.168.6.0/24>
> forceencaps=yes
> keyexchange=ikev1
> authby=secret
> auto=add
>
> -----------------------------------
>
> root at granville:~# ipsec status
> 000 "essex_brighton":
> 192.168.6.0/24===192.168.16.2:4500[ESSEX_PUB_IP]---192.168.16.1...BRIGHTON_PUB_IP:4500[BRIGHTON_PUB_IP]===192.168.0.0/24
> <http://192.168.6.0/24===192.168.16.2:4500[ESSEX_PUB_IP]---192.168.16.1...BRIGHTON_PUB_IP:4500[BRIGHTON_PUB_IP]===192.168.0.0/24>;
> erouted; eroute owner: #2
> 000 "essex_brighton": newest ISAKMP SA: #1; newest IPsec SA: #2;
> 000
> 000 #2: "essex_brighton" STATE_QUICK_I2 (sent QI2, IPsec SA
> established); EVENT_SA_REPLACE in 4s; newest IPSEC; eroute owner
> 000 #2: "essex_brighton" esp.9c28ba55 at BRIGHTON_PUB_IP (0 bytes)
> esp.c32b10a1 at 192.168.16.2 <mailto:esp.c32b10a1 at 192.168.16.2> (0 bytes);
> tunnel
> 000 #1: "essex_brighton" STATE_MAIN_I4 (ISAKMP SA established);
> EVENT_SA_REPLACE in 6962s; newest ISAKMP
> 000
>
>
> rodney:~# ipsec status
> 000 "essex_brighton":
> 192.168.0.0/24===BRIGHTON_PUB_IP:4500...ESSEX_PUB_IP:4500===192.168.6.0/24
> <http://192.168.0.0/24===BRIGHTON_PUB_IP:4500...ESSEX_PUB_IP:4500===192.168.6.0/24>;
> erouted; eroute owner: #3909
> 000 "essex_brighton": newest ISAKMP SA: #3898; newest IPsec SA: #3909;
> 000
> 000 #3909: "essex_brighton" STATE_QUICK_R2 (IPsec SA established);
> EVENT_SA_REPLACE in 3285s; newest IPSEC; eroute owner
> 000 #3909: "essex_brighton" esp.360fcd9e at ESSEX_PUB_IP (0 bytes)
> esp.295edd15 at BRIGHTON_PUB_IP (0 bytes); tunnel
> 000 #3899: "essex_brighton" STATE_QUICK_R2 (IPsec SA established);
> EVENT_SA_REPLACE in 446s
> 000 #3899: "essex_brighton" esp.c32b10a1 at ESSEX_PUB_IP (0 bytes)
> esp.9c28ba55 at BRIGHTON_PUB_IP (0 bytes); tunnel
> 000 #3898: "essex_brighton" STATE_MAIN_R3 (sent MR3, ISAKMP SA
> established); EVENT_SA_REPLACE in 7635s; newest ISAKMP
> 000
> Security Associations:
> none
>
> ------------------------
>
> root at granville:~# ip xfrm state
> src 192.168.16.2 dst BRIGHTON_PUB_IP
> proto esp spi 0x295edd15 reqid 16385 mode tunnel
> replay-window 32 flag af-unspec
> auth hmac(sha1) 0x0ba38e23a79f79f7f96690d2d166b315f60b60bb
> enc cbc(aes) 0xdf238a47bb128a41d94f60452411cd26
> encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
> src BRIGHTON_PUB_IP dst 192.168.16.2
> proto esp spi 0x360fcd9e reqid 16385 mode tunnel
> replay-window 32 flag af-unspec
> auth hmac(sha1) 0x015ec50f83fc414a681902bd935cf8560da4cbb2
> enc cbc(aes) 0x7e40d181e5c8ca5bfc35ed44b59c968d
> encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
> src 192.168.16.2 dst BRIGHTON_PUB_IP
> proto esp spi 0x9c28ba55 reqid 16385 mode tunnel
> replay-window 32 flag af-unspec
> auth hmac(sha1) 0x2345729df63869ea9a6df60f50508cf746860b02
> enc cbc(aes) 0xf90f83024f337ff85a8fc72392eaea8f
> encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
> src BRIGHTON_PUB_IP dst 192.168.16.2
> proto esp spi 0xc32b10a1 reqid 16385 mode tunnel
> replay-window 32 flag af-unspec
> auth hmac(sha1) 0x7f16f51d63369bec30ac74e4eef27d9a8ff81958
> enc cbc(aes) 0x047271d81f3a0483c34c0790fcc098c8
> encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
> root at granville:~# ip xfrm policy
> src 192.168.6.0/24 <http://192.168.6.0/24> dst 192.168.0.0/24
> <http://192.168.0.0/24>
> dir out priority 2344 ptype main
> tmpl src 192.168.16.2 dst BRIGHTON_PUB_IP
> proto esp reqid 16385 mode tunnel
> src 192.168.0.0/24 <http://192.168.0.0/24> dst 192.168.6.0/24
> <http://192.168.6.0/24>
> dir fwd priority 2344 ptype main
> tmpl src BRIGHTON_PUB_IP dst 192.168.16.2
> proto esp reqid 16385 mode tunnel
> src 192.168.0.0/24 <http://192.168.0.0/24> dst 192.168.6.0/24
> <http://192.168.6.0/24>
> dir in priority 2344 ptype main
> tmpl src BRIGHTON_PUB_IP dst 192.168.16.2
> proto esp reqid 16385 mode tunnel
> src ::/0 dst ::/0
> dir 4 priority 0 ptype main
> src ::/0 dst ::/0
> dir 3 priority 0 ptype main
> src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://0.0.0.0/0>
> dir 4 priority 0 ptype main
> src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://0.0.0.0/0>
> dir 3 priority 0 ptype main
> src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://0.0.0.0/0>
> dir 4 priority 0 ptype main
> src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://0.0.0.0/0>
> dir 3 priority 0 ptype main
> src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://0.0.0.0/0>
> dir 4 priority 0 ptype main
> src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://0.0.0.0/0>
> dir 3 priority 0 ptype main
> src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://0.0.0.0/0>
> dir 4 priority 0 ptype main
> src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://0.0.0.0/0>
> dir 3 priority 0 ptype main
> src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://0.0.0.0/0>
> dir 4 priority 0 ptype main
> src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://0.0.0.0/0>
> dir 3 priority 0 ptype main
> src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://0.0.0.0/0>
> dir 4 priority 0 ptype main
> src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://0.0.0.0/0>
> dir 3 priority 0 ptype main
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
--
======================================================================
Andreas Steffen andreas.steffen at strongswan.org
strongSwan - the Linux VPN Solution! www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==
More information about the Users
mailing list