[strongSwan] Packets not being encapsulated
Russ Cox
russ.cox at e-dba.com
Thu Mar 24 10:56:54 CET 2011
I've just done a few tcpdumps whilst running a ping from an Essex host
(6.11) to a Brighton one (0.7), eth1 is the external interface, eth0
internal - 192.168.16.0/24 is used between Granville and the router.
Is the last one of interest (bad udp cksum)?
Also, latest iptables output - packet count was increasing steadily whilst
running this ping.
Thanks again for your help guys
Russ
--------------------------------
root at granville:~# iptables -nvL |grep 192.168.6 |grep ipsec
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
11116 945K ACCEPT all -- * eth1 192.168.6.0/24
192.168.0.0/24 policy match dir out pol ipsec reqid 16385 proto 50
--------------------------------
root at granville:~# tcpdump -vvni eth1 |grep 192.168.0
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535
bytes
192.168.16.2 > 192.168.0.7: ICMP echo request, id 16663, seq 1008,
length 64
192.168.16.2 > 192.168.0.7: ICMP echo request, id 16663, seq 1009,
length 64
192.168.16.2 > 192.168.0.7: ICMP echo request, id 16663, seq 1010,
length 64
192.168.16.2 > 192.168.0.7: ICMP echo request, id 16663, seq 1011,
length 64
^C156 packets captured
156 packets received by filter
0 packets dropped by kernel
-----------------------------------
root at granville:~# tcpdump -vvni eth0 |grep 192.168.0
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535
bytes
192.168.6.11 > 192.168.0.7: ICMP echo request, id 16663, seq 1021,
length 64
192.168.6.11 > 192.168.0.7: ICMP echo request, id 16663, seq 1022,
length 64
192.168.6.11 > 192.168.0.7: ICMP echo request, id 16663, seq 1023,
length 64
192.168.6.11 > 192.168.0.7: ICMP echo request, id 16663, seq 1024,
length 64
192.168.6.11 > 192.168.0.7: ICMP echo request, id 16663, seq 1025,
length 64
^C100 packets captured
101 packets received by filter
0 packets dropped by kernel
------------------------------------
root at granville:~# tcpdump -vvni eth1 |grep 217.154.55.248
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535
bytes
192.168.16.2.4500 > BRIGHTON_PUB_IP.4500: [bad udp cksum 1e19!]
isakmp-nat-keep-alive
192.168.16.2.4500 > BRIGHTON_PUB_IP.4500: [bad udp cksum 1e19!]
isakmp-nat-keep-alive
192.168.16.2.4500 > BRIGHTON_PUB_IP.4500: [bad udp cksum 1e19!]
isakmp-nat-keep-alive
^C12454 packets captured
12455 packets received by filter
0 packets dropped by kernel
On 23 March 2011 20:56, Andreas Steffen <andreas.steffen at strongswan.org>wrote:
> In your iptables listing I see 7607 outbound packets on
> granville that are supposed to get ESP-encrypted.
> Where do they end up?
>
> Andreas
>
> On 23.03.2011 17:52, Russ Cox wrote:
> > 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
> >
>
>
> ======================================================================
> 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]==
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20110324/7ba3accc/attachment.html>
More information about the Users
mailing list