I've managed to get this working, but I don't yet understand why it wasn't with the old config - <br>I'm basically now using an alternative network for either end of the tunnel, and netmapping source and destination addresses with iptables.<br>
<br>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 (<a href="http://192.168.0.0/24">192.168.0.0/24</a> and <a href="http://192.168.6.0/24">192.168.6.0/24</a>) in the ipsec config, I can only guess there's something else in my iptables script messing with things.<br>
<br>What do you reckon, it would be handy to know for the future where I've gone wrong.<br><br>Cheers all, have a good weekend.<br><br>Russ<br><br>--------------------------<br>ipsec.conf on Granville in Essex office<br>
<br>conn essex_brighton<br> left=%defaultroute<br> leftid=ESSEX_PUB_IP<br> leftsubnet=<a href="http://172.16.1.0/24">172.16.1.0/24</a><br> leftfirewall=yes<br> right=BRIGHTON_PUB_IP<br>
rightsubnet=<a href="http://172.16.0.0/24">172.16.0.0/24</a><br>
forceencaps=yes<br> keyexchange=ikev2<br> authby=secret<br> auto=add<br>-----------------------------<br>ipsec.conf on Rodney in Brighton office<br><br>conn essex_brighton<br> left=BRIGHTON_PUB_IP<br>
leftsubnet=<a href="http://172.16.0.0/24">172.16.0.0/24</a><br> leftfirewall=yes<br> right=ESSEX_PUB_IP<br> rightsubnet=<a href="http://172.16.1.0/24">172.16.1.0/24</a><br> forceencaps=yes<br>
keyexchange=ikev2<br> authby=secret<br> auto=add<br>----------------------------<br>iptables netmap rules on Rodney<br><br>$IPTABLES -t nat -A PREROUTING -s <a href="http://192.168.0.0/24">192.168.0.0/24</a> -d <a href="http://192.168.6.0/24">192.168.6.0/24</a> -j NETMAP --to <a href="http://172.16.1.0/24">172.16.1.0/24</a><br>
$IPTABLES -t nat -A POSTROUTING -s <a href="http://192.168.0.0/24">192.168.0.0/24</a> -d <a href="http://172.16.1.0/24">172.16.1.0/24</a> -j NETMAP --to <a href="http://172.16.0.0/24">172.16.0.0/24</a><br>$IPTABLES -t nat -A PREROUTING -s <a href="http://172.16.1.0/24">172.16.1.0/24</a> -d <a href="http://172.16.0.0/24">172.16.0.0/24</a> -j NETMAP --to <a href="http://192.168.0.0/24">192.168.0.0/24</a><br>
$IPTABLES -t nat -A POSTROUTING -s <a href="http://172.16.1.0/24">172.16.1.0/24</a> -d <a href="http://192.168.0.0/24">192.168.0.0/24</a> -j NETMAP --to <a href="http://192.168.6.0/24">192.168.6.0/24</a><br>----------------------------<br>
iptables netmap rules on Granville<br><br>$IPTABLES -t nat -A PREROUTING -s <a href="http://192.168.6.0/24">192.168.6.0/24</a> -d <a href="http://192.168.0.0/24">192.168.0.0/24</a> -j NETMAP --to <a href="http://172.16.0.0/24">172.16.0.0/24</a><br>
$IPTABLES -t nat -A POSTROUTING -s <a href="http://192.168.6.0/24">192.168.6.0/24</a> -d <a href="http://172.16.0.0/24">172.16.0.0/24</a> -j NETMAP --to <a href="http://172.16.1.0/24">172.16.1.0/24</a><br>$IPTABLES -t nat -A PREROUTING -s <a href="http://172.16.0.0/24">172.16.0.0/24</a> -d <a href="http://172.16.1.0/24">172.16.1.0/24</a> -j NETMAP --to <a href="http://192.168.6.0/24">192.168.6.0/24</a><br>
$IPTABLES -t nat -A POSTROUTING -s <a href="http://172.16.0.0/24">172.16.0.0/24</a> -d <a href="http://192.168.6.0/24">192.168.6.0/24</a> -j NETMAP --to <a href="http://192.168.0.0/24">192.168.0.0/24</a><br>---------------------------<br>
<br><br><br><div class="gmail_quote">On 24 March 2011 09:56, Russ Cox <span dir="ltr"><<a href="mailto:russ.cox@e-dba.com">russ.cox@e-dba.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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 - <a href="http://192.168.16.0/24" target="_blank">192.168.16.0/24</a> is used between Granville and the router.<br>
<br>Is the last one of interest (bad udp cksum)?<br><br>Also, latest iptables output - packet count was increasing steadily whilst running this ping.<br><br>Thanks again for your help guys<br><br>Russ<br>--------------------------------<br>
root@granville:~# iptables -nvL |grep 192.168.6 |grep ipsec<div class="im"><br> 0 0 ACCEPT all -- eth1 * <a href="http://192.168.0.0/24" target="_blank">192.168.0.0/24</a> <a href="http://192.168.6.0/24" target="_blank">192.168.6.0/24</a> policy match dir in pol ipsec reqid 16385 proto 50 <br>
</div>
11116 945K ACCEPT all -- * eth1 <a href="http://192.168.6.0/24" target="_blank">192.168.6.0/24</a> <a href="http://192.168.0.0/24" target="_blank">192.168.0.0/24</a> policy match dir out pol ipsec reqid 16385 proto 50 <br>
<br>--------------------------------<br>
root@granville:~# tcpdump -vvni eth1 |grep 192.168.0<br>tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes<br> 192.168.16.2 > <a href="http://192.168.0.7" target="_blank">192.168.0.7</a>: ICMP echo request, id 16663, seq 1008, length 64<br>
192.168.16.2 > <a href="http://192.168.0.7" target="_blank">192.168.0.7</a>: ICMP echo request, id 16663, seq 1009, length 64<br> 192.168.16.2 > <a href="http://192.168.0.7" target="_blank">192.168.0.7</a>: ICMP echo request, id 16663, seq 1010, length 64<br>
192.168.16.2 > <a href="http://192.168.0.7" target="_blank">192.168.0.7</a>: ICMP echo request, id 16663, seq 1011, length 64<br>^C156 packets captured<br>156 packets received by filter<br>0 packets dropped by kernel<br>
-----------------------------------<br>
root@granville:~# tcpdump -vvni eth0 |grep 192.168.0<br>tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes<br> 192.168.6.11 > <a href="http://192.168.0.7" target="_blank">192.168.0.7</a>: ICMP echo request, id 16663, seq 1021, length 64<br>
192.168.6.11 > <a href="http://192.168.0.7" target="_blank">192.168.0.7</a>: ICMP echo request, id 16663, seq 1022, length 64<br> 192.168.6.11 > <a href="http://192.168.0.7" target="_blank">192.168.0.7</a>: ICMP echo request, id 16663, seq 1023, length 64<br>
192.168.6.11 > <a href="http://192.168.0.7" target="_blank">192.168.0.7</a>: ICMP echo request, id 16663, seq 1024, length 64<br> 192.168.6.11 > <a href="http://192.168.0.7" target="_blank">192.168.0.7</a>: ICMP echo request, id 16663, seq 1025, length 64<br>
^C100 packets captured<br>101 packets received by filter<br>0 packets dropped by kernel<br>------------------------------------<br>root@granville:~# tcpdump -vvni eth1 |grep 217.154.55.248<br>tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes<br>
192.168.16.2.4500 > BRIGHTON_PUB_IP.4500: [bad udp cksum 1e19!] isakmp-nat-keep-alive<br> 192.168.16.2.4500 > BRIGHTON_PUB_IP.4500: [bad udp cksum 1e19!] isakmp-nat-keep-alive<br> 192.168.16.2.4500 > BRIGHTON_PUB_IP.4500: [bad udp cksum 1e19!] isakmp-nat-keep-alive<br>
^C12454 packets captured<br>12455 packets received by filter<br>0 packets dropped by kernel<div><div></div><div class="h5"><br><br><br><br><div class="gmail_quote">On 23 March 2011 20:56, Andreas Steffen <span dir="ltr"><<a href="mailto:andreas.steffen@strongswan.org" target="_blank">andreas.steffen@strongswan.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">In your iptables listing I see 7607 outbound packets on<br>
granville that are supposed to get ESP-encrypted.<br>
Where do they end up?<br>
<font color="#888888"><br>
Andreas<br>
</font><div><br>
On 23.03.2011 17:52, Russ Cox wrote:<br>
> Hi Andreas,<br>
><br>
> Thanks for the quick reply!<br>
><br>
> I don't block anything at all outbound on either machine, plus the<br>
> OUTPUT chain on both is set to ACCEPT<br>
><br>
> I'm not 100% sure I've answered your question - shout back if you need<br>
> any more info<br>
><br>
> Cheers<br>
><br>
> Russ<br>
><br>
<br>
<br>
</div><div><div></div><div>======================================================================<br>
Andreas Steffen <a href="mailto:andreas.steffen@strongswan.org" target="_blank">andreas.steffen@strongswan.org</a><br>
strongSwan - the Linux VPN Solution! <a href="http://www.strongswan.org" target="_blank">www.strongswan.org</a><br>
Institute for Internet Technologies and Applications<br>
University of Applied Sciences Rapperswil<br>
CH-8640 Rapperswil (Switzerland)<br>
===========================================================[ITA-HSR]==<br>
</div></div></blockquote></div><br><br clear="all"><br><br><br><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Russ Cox<br>Systems Engineer<br><br>e-DBA Ltd.<br>48A Old Steine,<br>Brighton, East Sussex,<br>BN1 1NH<br><br>Main: +44 (0) 870 366 7800<br>Direct: +44 (0) 127 322 4704<br>
email: <a href="mailto:russ.cox@e-dba.net">russ.cox@e-dba.net</a><br>Msn: <a href="mailto:russ.cox@e-dba.com">russ.cox@e-dba.com</a><br>Skype: russc0x<br><br>Company No: 365969<br><br>Oracle Partner of the Year<br>
General Business Technology<br><br>UKOUG Partner of the year<br>(4 categories)<br><br><br><br><br>