[Swan] Does libreswan v3.20 support multiple clients behind NAT to communicate with public server simultaneously?
Hao Chen
earthlovepython at outlook.com
Tue Oct 31 05:58:38 UTC 2017
Hi All:
I still cannot let 2 private clients behind NAT to communicate public server simultaneous. Can you please help me?
Thanks in advance.
Following is my today's (failed) test procedure
===================================================
I configured "reqid" in IPSecXYZ.conf on public server machine. After that, "ip xfrm state" shows that the value is really set successfully.
Since there are 2 private clients, so the total # of "ip xfrm state" is 2*2==4. But "ip xfrm pol" only shows 2 instead of 4.
I remember http://swan.libreswan.narkive.com/Rxj6YbXK/cannot-install-eroute-when-second-client-connected-from-behind-the-same-nat reads "but you still need some iptables rules based on the reqid to ensure these two flows will work properly" . So I speculate that "ip xfrm pol" cannot "recognize" 2 "duplicated" record ???? (Maybe I am wrong because I define "overlapip" in IPSecXYZ.conf ???)
So I added following "iptables" rules on public IP server like following:
iptables -t mangle -I PREROUTING -m policy --dir in --reqid 16344 -j MARK --set-mark 16344
iptables -t mangle -I PREROUTING -m policy --dir in --reqid 16335 -j MARK --set-mark 16335
iptables -t mangle -I POSTROUTING -m policy --dir out --reqid 16344 -j MARK --set-mark 16344
iptables -t mangle -I POSTROUTING -m policy --dir out --reqid 16335 -j MARK --set-mark 16335
But still no luck. So have to get help from you again.
My System information:
===============================
Libreswan: 3.20 (netkey) on 3.10.0-693.el7.x86_64
Red Hat Enterprise Linux Server 7.4 (Maipo)
iptables: 1.4.21
Network topology
===============================
2 private client (private ip: 192.168.161.x) connect to NAT-GW (private IP: 192.168.161.x, public IP: 10.0.161.34).
Public server (public ip: 10.0.146.196)
IPSec.conf on public server for 1st private client:
===============================
conn 196to44
ike=aes256-md5;modp1536
authby=secret
aggrmode=no
ikelifetime=14409s
ikev2=yes
phase2=esp
type=transport
pfs=yes
rekey=yes
rekeymargin=540s
phase2alg=3des,aes256-md5;modp1536
salifetime=3600s
# local
leftid=10.0.146.196
left=10.0.146.196
# remote
rightid=192.168.161.44
right=10.0.161.34
rightsubnet=192.168.161.0/24
overlapip=yes
reqid=16344
auto=start
IPSec.conf on public server for 2nd private client:
===============================
conn 196to35
ike=aes256-md5;modp1536
authby=secret
aggrmode=no
ikelifetime=14409s
ikev2=yes
phase2=esp
type=transport
pfs=yes
rekey=yes
rekeymargin=540s
phase2alg=3des,aes256-md5;modp1536
salifetime=3600s
# local
leftid=10.0.146.196
left=10.0.146.196
# remote
rightid=192.168.161.35
right=10.0.161.34
rightsubnet=192.168.161.0/24
overlapip=yes
reqid=16335
auto=start
IPSec configuration on 1st private client:
===============================
conn ipv4tran44
ike=aes256-md5;modp1536
authby=secret
aggrmode=no
ikelifetime=14409s
ikev2=yes
phase2=esp
type=transport
pfs=yes
rekey=yes
rekeymargin=540s
phase2alg=3des,aes256-md5;modp1536
salifetime=3600s
# local
leftid=192.168.161.44
left=192.168.161.44
leftsubnet=192.168.161.0/24
# Remote
rightid=10.0.146.196
right=10.0.146.196
auto=start
IPSec configuration on 2nd private client:
===============================
conn ipv4tran35
ike=aes256-md5;modp1536
authby=secret
aggrmode=no
ikelifetime=14409s
ikev2=yes
phase2=esp
type=transport
pfs=yes
rekey=yes
rekeymargin=540s
phase2alg=3des,aes256-md5;modp1536
salifetime=3600s
# local
leftid=192.168.161.35
left=192.168.161.35
leftsubnet=192.168.161.0/24
# Remote
rightid=10.0.146.196
right=10.0.146.196
auto=start
configuration on NAT-GW machine
===============================
service ipsec stop
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp
echo 1 > /proc/sys/net/ipv4/conf/eth3/proxy_arp
iptables -t nat -A POSTROUTING -p TCP -o eth1 -j SNAT --to-source 10.0.161.34:20000-40000
iptables -t nat -A POSTROUTING -p UDP -o eth1 -j SNAT --to-source 10.0.161.34:40000-60000
configuration on public server machine
===============================
iptables -t mangle -I PREROUTING -m policy --dir in --reqid 16344 -j MARK --set-mark 16344
iptables -t mangle -I PREROUTING -m policy --dir in --reqid 16335 -j MARK --set-mark 16335
iptables -t mangle -I POSTROUTING -m policy --dir out --reqid 16344 -j MARK --set-mark 16344
iptables -t mangle -I POSTROUTING -m policy --dir out --reqid 16335 -j MARK --set-mark 16335
Thanks and regards
Hao Chen
________________________________
From: Swan <swan-bounces at lists.libreswan.org> on behalf of Hao Chen <earthlovepython at outlook.com>
Sent: Monday, October 30, 2017 10:36
To: Paul Wouters
Cc: swan at lists.libreswan.org
Subject: Re: [Swan] Does libreswan v3.20 support multiple clients behind NAT to communicate with public server simultaneously?
Hi Paul / all:
Paul: Thanks for your response at first !
1.
(1).
In previous email, you mentioned "mark=-1/0xffffffff" and "Instead of NAT". Are you saying, I shall run "iptables -t mangle" on private client???
But it does NOT take effect after I run "iptables -t mangle -A POSTROUTING -p esp -m policy --dir out -s 192.168.161.44 -d 10.0.146.196 -j MARK --set-mark 16344" on private client.
After I run above command, "ip xfrm state" still shows reqid as "16397" on private client.
Only after I configure "reqid" in ipsecXX.conf on private machine, "ip xfrm state" shows the value which I configured.
(By the way, on public server side, "reqid" (output of "ip xfrm state") is changed after I configure "reqid" in IPSecXXX.conf also.)
(2).
Can you please tell me where to run "iptables -t mangle --set-mask"? On private client or public server?
2.
http://swan.libreswan.narkive.com/Rxj6YbXK/cannot-install-eroute-when-second-client-connected-from-behind-the-same-nat writes "still need some iptables rules based on the reqid to ensure these two flows" .
https://libreswan.org/wiki/SAref_code writes "When a packet is sent out, it will pass through iptables. Libreswan maintains an IPSEC chain in the mangle table. This allows it to tag packets using xmark".
>From above links, looks like "iptables -t mangle" is used for some work. but https://linux.die.net/man/8/iptables writes "--set-mark mark " "It can for example be used in conjunction with iproute2"
Can you please give some clue(links) about how does "--set-mark mark " work with IPsec(xfrm)?
Thanks
________________________________
From: Paul Wouters <paul at nohats.ca>
Sent: Thursday, October 26, 2017 18:53
To: Hao Chen
Cc: swan at lists.libreswan.org
Subject: Re: [Swan] Does libreswan v3.20 support multiple clients behind NAT to communicate with public server simultaneously?
On Thu, 26 Oct 2017, Hao Chen wrote:
> at first, without configuring "overlapid=yes", pluto.log report "cannot install eroute, it is in use for XXXX" for the 2nd startup client.
>
> Only 1st client can communicate with public sever in all time.
> No matter how many times I restart IPsec on 2nd machine, pluto.log on public server report "cannot install eroute, it is in use for XXXX".
>
>
> 2.
> Get some clue from http://swan.libreswan.narkive.com/Rxj6YbXK/cannot-install-eroute-when-second-client-connected-from-behind-the-same-nat
"cannot install eroute" when second client connected from ...<http://swan.libreswan.narkive.com/Rxj6YbXK/cannot-install-eroute-when-second-client-connected-from-behind-the-same-nat>
swan.libreswan.narkive.com
"cannot install eroute" when second client connected from behind the same NAT
> I configured "overlapid=yes" on server side. And added 2 IPTables rule on NAT-GW:
Instead of NAT, use:
mark=-1/0xffffffff
This should install the policies with a unique mark for each connection.
When used with overlapip=yes, it should install multiple policies to
the same IPs with the mark causing the rules to be different and not
clash.
The only limitation is that traffic must be initiated from the client,
to get the initial MARK. If multiple clients clash, then you cannot
from the server connect to the one IP and expect to reach one or the
other. But in the typical use of IPsec Transport Mode with L2TP, it
is always the client generating the traffic so this solution works.
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20171031/8d1732c4/attachment-0001.html>
More information about the Swan
mailing list