[strongSwan] net2net can not work well on ubuntu14.04
mounter625
13621209832 at 163.com
Sat May 9 15:18:28 CEST 2015
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> wrote:
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>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
>>>> https://lists.strongswan.org/mailman/listinfo/users
>>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.strongswan.org
>>> https://lists.strongswan.org/mailman/listinfo/users
>>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.strongswan.org
>> https://lists.strongswan.org/mailman/listinfo/users
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v2
>
>iQIcBAEBCAAGBQJVTUUkAAoJEDg5KY9j7GZYKrkQAKABtzux3tJnOjGqAYq5ybkU
>Mk+55ys+JtHwnkXowXGQY+Iv7Dy1w9zccZ5N11hRo1pnFDfhh4qHlTKmbTBKNBYu
>dIHg61NLm7ocbbpya/VIgMmvxzydFXJkd1hWUoc3H01nxs60yozGLMeLId8hZFpT
>ZjyoH16+QMWO0y6ORb8PGn8vj4+gra1mxn2q+bdEKzAiiKIYrgK8zOrNH33epXTi
>MBK9U8BsWIsEkHgHEuzKIBuGVbqOiHTaxvFuZwk8gHo/jUBZpRV+nAnZMDBCF7Xf
>bm5B7WOUnX72y+kO4FV5ZCdYlyPsS+LD+2I0uvZCsIgpB7Y6fUDhkE+lS0vvl4xX
>hv1RFeXrpGAAVP9Pk6Qi/iV38enF+kQX2ORvaeMXoARaaTheFVsJdpGkU8IVx1Ej
>/FwVYiKX9A//HiKYFhhJjIQsXVDygdDJajk16KM51sqqzGOqPzkGfbYvMDsCs+sK
>M6RZSlrMHhCqVsbGhGpp3QMY9secQeYv/9VvJZS6MWKu/cqBGE3OzzPvqmbdVbua
>Wmf6RwtInQGU6L8ud7yPs2/JbAy+aebQuftFtIrNG1R7AL+uDjQa/0qDD8On48gr
>BiEa9jLkXZfuO50fmNrwWarGBmLPav1Srvp5awWfumXmHSehR3vKz6KFpGQF/swL
>G3rKH0I1YPw3S53nlAuC
>=9PWR
>-----END PGP SIGNATURE-----
>
来自 网易手机号码邮箱 -- 有手机就有网易手机号码邮箱，了解详情>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150509/9ad4ce65/attachment-0001.html>
More information about the Users
mailing list