[strongSwan] net2net can not work well on ubuntu14.04

Tue May 19 17:52:02 CEST 2015

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello,

The ipsec encapsulation is not governed by the routing table, but
by XFRM policies in the kernel. The rules in the table are just there to fix reverse path filter
problems and other shennanigans.

Mit freundlichen Grüßen/Kind Regards,
Noel Kuntze

GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

Am 09.05.2015 um 15:18 schrieb mounter625:
> Hi, Noel
>
> I think this is a bug of strongswan. When strongswan run as vpn gateway, there is another default ip, the packets from the hosts will not pass this vpn tunnel.
> network topology:
>
> 10.1.0.10 <---->10.1.0.1 (moon) 192.168.0.1<----->192.168.0.2 (sun) 10.2.0.1<---->10.2.0.10
> moon has another default gw(1.1.1.1), that is, the packets from 10.1.0.10 to 10.2.0.10 will not hit this rule "10.2.0.0/16 via 192.168.0.2 dev eth0 proto static src 10.1.0.1 ", and the packets from 10.1.0.10 to 10.2.0.10 will be sent to default gw (1.1.1.1). Then these packets will not pass vpn tunnel to 10.2.0.10.
>
> So it is not correct. Maybe we should add a new route rule in table 220.
> 10.2.0.0/16 via 192.168.0.2 dev eth0 proto static src 10.1.0.10
>
> Then the packets from 10.1.0.10 to 10.2.0.10 will pass vpn tunnle to reach 10.2.0.10.
>
> If any problem, please let me know.
>
> Thanks a lot.
> Zhu Yanjun
>
> At 2015-05-09 21:07:20, "mounter625" <13621209832 at 163.com> wrote:
>
>     Hi, Neol
>
>     I checked route table 220, and found this rule:
>
>     10.2.0.0/16 via 192.168.0.2 dev eth0 proto static src 10.1.0.1
>
>     I think this rule only permit src address 10.1.0.1 packets to pass eth0. The other src address packets will not hit this route rule.
>
>     Maybe this is the root cause.
>
>     Best Regards!
>     Zhu Yanjun
>
>
>
>
>
>     At 2015-05-09 07:22:12, "Noel Kuntze" <noel at familie-kuntze.de <mailto:noel at familie-kuntze.de>> wrote:
>     >
> Hello Zhuyj,
>
> Please check the routing in your network. The answer packets from the host you are
> trying to ping need to reach back the client. See [1] for information
>
> [1] https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling#Hosts-on-the-LAN
>
> Mit freundlichen Grüßen/Kind Regards,
> Noel Kuntze
>
> GPG Key ID: 0x63EC6658
> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
>
> Am 08.05.2015 um 12:18 schrieb zhuyj:
> > On moon:
>
> > I found the icmp does not pass vpn tunnel instead these icmp packets pass eth1 directly.
> > I created a vpn tunnel through eth1.
>
> > tcpdump -ni eth1 icmp
> > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> > listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
> > 18:13:50.095301 IP 10.1.0.10 > 10.2.0.1: ICMP echo request, id 1757, seq 37, length 64
> > 18:13:50.095465 IP 10.2.0.1 > 10.1.0.10: ICMP echo reply, id 1757, seq 37, length 64
> > 18:13:51.103324 IP 10.1.0.10 > 10.2.0.1: ICMP echo request, id 1757, seq 38, length 64
> > 18:13:51.103478 IP 10.2.0.1 > 10.1.0.10: ICMP echo reply, id 1757, seq 38, length 64
>
> > Does anyone has idea?
>
> > Any reply is appreciated.
>
> > Zhu Yanjun
>
> > On 05/08/2015 06:14 PM, yzhu1 wrote:
> >> On moon:
> >> Iptables rules:
> >>
> >> # Generated by iptables-save v1.4.21 on Fri May  8 18:10:58 2015
> >> *filter
> >> :INPUT ACCEPT [4274:596163]
> >> :FORWARD ACCEPT [0:0]
> >> :OUTPUT ACCEPT [190:20743]
> >> -A INPUT -s 10.2.0.0/16 -d 10.4.0.1/32 -i eth1 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
> >> -A FORWARD -s 10.2.0.0/16 -d 10.4.0.1/32 -i eth1 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
> >> -A FORWARD -s 10.4.0.1/32 -d 10.2.0.0/16 -o eth1 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
> >> -A OUTPUT -s 10.4.0.1/32 -d 10.2.0.0/16 -o eth1 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
> >> COMMIT
> >> # Completed on Fri May  8 18:10:58 2015
> >>
> >>  ip -4 r s table all
> >> 10.2.0.0/16 via 192.168.0.2 dev eth1  table 220  proto static  src 10.4.0.1
> >> default via 128.224.162.1 dev eth0  proto static
> >> 10.1.0.0/16 dev eth2  proto kernel  scope link  src 10.1.0.1
> >> 128.224.162.0/23 dev eth0  proto kernel  scope link  src 128.224.163.143  metric 1
> >> 192.168.0.0/24 dev eth1  proto kernel  scope link  src 192.168.0.1
> >> broadcast 10.1.0.0 dev eth2  table local  proto kernel  scope link  src 10.1.0.1
> >> local 10.1.0.1 dev eth2  table local  proto kernel  scope host src 10.1.0.1
> >> broadcast 10.1.255.255 dev eth2  table local  proto kernel  scope link  src 10.1.0.1
> >> local 10.4.0.1 dev eth1  table local  proto kernel  scope host src 10.4.0.1
> >> broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link src 127.0.0.1
> >> local 127.0.0.0/8 dev lo  table local  proto kernel  scope host src 127.0.0.1
> >> local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 127.0.0.1
> >> broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link  src 127.0.0.1
> >> broadcast 128.224.162.0 dev eth0  table local  proto kernel  scope link  src 128.224.163.143
> >> local 128.224.163.143 dev eth0  table local  proto kernel  scope host  src 128.224.163.143
> >> broadcast 128.224.163.255 dev eth0  table local  proto kernel scope link  src 128.224.163.143
> >> broadcast 192.168.0.0 dev eth1  table local  proto kernel  scope link  src 192.168.0.1
> >> local 192.168.0.1 dev eth1  table local  proto kernel  scope host src 192.168.0.1
> >> broadcast 192.168.0.255 dev eth1  table local  proto kernel  scope link  src 192.168.0.1
> >>
> >> cat /proc/sys/net/ipv4/ip_forward
> >> 1
> >>
> >>
> >> On 05/08/2015 06:01 PM, zhuyj wrote:
> >>> Hi, all
> >>>
> >>> I configured 4 vmare hosts. The hosts are ubuntu14.04. The gateway moon does not forward icmp packets.
> >>>
> >>> The network topology is as below.
> >>>
> >>> 10.1.0.10 <---->10.1.0.1 (moon) 192.168.0.1<----->192.168.0.2 (sun) 10.2.0.1<---->10.2.0.10
> >>>
> >>> strongswan is 5.3.0.
> >>>
> >>> On moon
> >>> /usr/local/etc/ipsec.conf is as below:
> >>>
> >>> config setup
> >>>
> >>> conn %default
> >>>     ikelifetime=60m
> >>>     keylife=20m
> >>>     rekeymargin=3m
> >>>     keyingtries=1
> >>>     authby=secret
> >>>     keyexchange=ikev2
> >>>     mobike=no
> >>>
> >>> conn net-net
> >>>     left=%defaultroute
> >>>     leftsourceip=%config
> >>>     leftfirewall=yes
> >>>     leftid=@moon.strongswan.org
> >>>     right=192.168.0.2
> >>>     rightsubnet=10.2.0.0/16
> >>>     rightid=@sun.strongswan.org
> >>>     auto=add
> >>> /usr/local/etc/ipsec.secrets is as below:
> >>>
> >>> : PSK 0sFpZAZqEN6Ti9sqt4ZP5EWcqx
> >>>
> >>> On Sun
> >>> /usr/local/etc/ipsec.conf is as below:
> >>> config setup
> >>>
> >>> conn %default
> >>>     ikelifetime=60m
> >>>     keylife=20m
> >>>     rekeymargin=3m
> >>>     keyingtries=1
> >>>     authby=secret
> >>>     keyexchange=ikev2
> >>>     mobike=no
> >>>
> >>> conn net-net
> >>>     left=192.168.0.2
> >>>     leftsubnet=10.2.0.0/16
> >>>     leftid=@sun.strongswan.org
> >>>     leftfirewall=yes
> >>>     right=192.168.0.1
> >>>     rightid=@moon.strongswan.org
> >>>     auto=add
> >>>     rightsourceip=10.4.0.0/24
> >>>
> >>> /usr/local/etc/ipsec.secrets is as below:
> >>>
> >>> : PSK 0sFpZAZqEN6Ti9sqt4ZP5EWcqx
> >>>
> >>> Others remain unchanged.
> >>>
> >>> I ran "ping 10.2.0.10" on clinet 10.1.0.10. But I can not get any reply from 10.2.0.10.
> >>>
> >>> I can find the icmp packets into moon. But moon will not forward these icmp packets.
> >>>
> >>> After an iptables rule (iptables -t nat -A POSTROUTING -s 10.4.0.0/16 -j MASQUERADE) is run in
> >>> sun, I can ping 10.2.0.10 on moon.
> >>>
> >>> But I can not ping 10.2.0.1 on client 10.1.0.10.
> >>>
> >>> That is, moon can reach client 10.2.0.10.But client 10.10.10 can not reach sun.
> >>>
> >>> 10.1.0.10 <---->10.1.0.1 (moon) 192.168.0.1<----->192.168.0.2 (sun) 10.2.0.1<---->10.2.0.10
> >>> icmp------------------------------------------------------------------>here
> >>> icmp----------->
> >>>
> >>> In a word, moon can not forward icmp packets.
> >>>
> >>> Does any one have the similar experience?
> >>>
> >>> Any reply is appreciated.
> >>>
> >>> Thanks a lot.
> >>> Zhu Yanjun
> >>>
> >>>
> >>> _______________________________________________
> >>> Users mailing list
> >>> Users at lists.strongswan.org <mailto:Users at lists.strongswan.org>
> >>> https://lists.strongswan.org/mailman/listinfo/users
> >>>
> >>
> >> _______________________________________________
> >> Users mailing list
> >> Users at lists.strongswan.org <mailto:Users at lists.strongswan.org>
> >> https://lists.strongswan.org/mailman/listinfo/users
> >>
>
>
> > _______________________________________________
> > Users mailing list
> > Users at lists.strongswan.org <mailto:Users at lists.strongswan.org>
> > https://lists.strongswan.org/mailman/listinfo/users
>
>     >
>
>
>
>     来自 *网易**手机号码邮箱* -- 有手机就有网易手机号码邮箱，了解详情> <http://shouji.163.com>
>
>
>
> 来自 *网易**手机号码邮箱* -- 有手机就有网易手机号码邮箱，立即使用> <http://shouji.163.com>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVW1wgAAoJEDg5KY9j7GZYlCwP+wXpxyEeTZoQF1U/Zr26vNED
fcjg8Q1jWS8MnF7LHApbyrtc0YWOKnCItwvcppdzkUKdR2cGPsPmW86c0XgZW0N1
OYHZkGtLNRbWwjwPfQfOCxAFx0CE7Mrq39AXRxkW8fLff3kLzVcLhZA+2E91i7d3
PJocgXMbNtMQke7AVdWX4R6wJf9L79gAEXnWzZ1pWtU4h0RfkE60s7VjhP6dozqN
Umrv7+/cIgByUu15odEhxS0rvp0jUL1gnl3QilQJ67yxXGFxj2AHckEpptJTH9F+
ck+UcpQSU3Da3bgHuVsXvqIbNOQmEEavZl3Eu6sz0Ab+fn2RKIrGucOKeweSjpvl
ngTWuM1qTuIgQODQfB4dbRYoMKryiQwh6E5ttFRelzNLnq7+fEfOWR+yRkvUouCv
BaB1Yj1kpWNRIrLTQ3BBsKs4z3GyZB7anClJNRRYfBEMRvdO6NnHeDo03u00LGH9
Z1BN8+oGYizeN44O4r1HNQd9bmmBT/Lc9epHAvfStNvrViy7SGcXFZAbWIUK7Bo5
sw7QxIJh86rPQYJU66UaZ/wrc6f8XHnOd1i8EifJcNX+3rjUpvobDFKUEQvn/Y4a
n+lTBi50Urfv0Gf/06r2ankwTKkTTeYLguxTpTSvJC8I7zOXEtw/Fwy9QCAzZncz
yJS8KGyy+t2vMBdL8ala
=b3qQ
-----END PGP SIGNATURE-----