[strongSwan] Packets not being encapsulated
Russ Cox
russ.cox at e-dba.com
Fri Mar 25 18:34:24 CET 2011
I've managed to get this working, but I don't yet understand why it wasn't
with the old config -
I'm basically now using an alternative network for either end of the tunnel,
and netmapping source and destination addresses with iptables.
Packets get encapsulated fine and everything works nicely, but it was a lot
of hassle and I'd like to know why it wouldn't work when specifying my
actual network ranges (192.168.0.0/24 and 192.168.6.0/24) in the ipsec
config, I can only guess there's something else in my iptables script
messing with things.
What do you reckon, it would be handy to know for the future where I've gone
wrong.
Cheers all, have a good weekend.
Russ
--------------------------
ipsec.conf on Granville in Essex office
conn essex_brighton
left=%defaultroute
leftid=ESSEX_PUB_IP
leftsubnet=172.16.1.0/24
leftfirewall=yes
right=BRIGHTON_PUB_IP
rightsubnet=172.16.0.0/24
forceencaps=yes
keyexchange=ikev2
authby=secret
auto=add
-----------------------------
ipsec.conf on Rodney in Brighton office
conn essex_brighton
left=BRIGHTON_PUB_IP
leftsubnet=172.16.0.0/24
leftfirewall=yes
right=ESSEX_PUB_IP
rightsubnet=172.16.1.0/24
forceencaps=yes
keyexchange=ikev2
authby=secret
auto=add
----------------------------
iptables netmap rules on Rodney
$IPTABLES -t nat -A PREROUTING -s 192.168.0.0/24 -d 192.168.6.0/24 -j NETMAP
--to 172.16.1.0/24
$IPTABLES -t nat -A POSTROUTING -s 192.168.0.0/24 -d 172.16.1.0/24 -j NETMAP
--to 172.16.0.0/24
$IPTABLES -t nat -A PREROUTING -s 172.16.1.0/24 -d 172.16.0.0/24 -j NETMAP
--to 192.168.0.0/24
$IPTABLES -t nat -A POSTROUTING -s 172.16.1.0/24 -d 192.168.0.0/24 -j NETMAP
--to 192.168.6.0/24
----------------------------
iptables netmap rules on Granville
$IPTABLES -t nat -A PREROUTING -s 192.168.6.0/24 -d 192.168.0.0/24 -j NETMAP
--to 172.16.0.0/24
$IPTABLES -t nat -A POSTROUTING -s 192.168.6.0/24 -d 172.16.0.0/24 -j NETMAP
--to 172.16.1.0/24
$IPTABLES -t nat -A PREROUTING -s 172.16.0.0/24 -d 172.16.1.0/24 -j NETMAP
--to 192.168.6.0/24
$IPTABLES -t nat -A POSTROUTING -s 172.16.0.0/24 -d 192.168.6.0/24 -j NETMAP
--to 192.168.0.0/24
---------------------------
On 24 March 2011 09:56, Russ Cox <russ.cox at e-dba.com> wrote:
> 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]==
>>
>
>
>
>
>
>
>
--
Russ Cox
Systems Engineer
e-DBA Ltd.
48A Old Steine,
Brighton, East Sussex,
BN1 1NH
Main: +44 (0) 870 366 7800
Direct: +44 (0) 127 322 4704
email: russ.cox at e-dba.net
Msn: russ.cox at e-dba.com
Skype: russc0x
Company No: 365969
Oracle Partner of the Year
General Business Technology
UKOUG Partner of the year
(4 categories)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20110325/c93a280d/attachment.html>
More information about the Users
mailing list