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 <[email protected]> on behalf of Hao Chen 
<[email protected]>
Sent: Monday, October 30, 2017 10:36
To: Paul Wouters
Cc: [email protected]
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 <[email protected]>
Sent: Thursday, October 26, 2017 18:53
To: Hao Chen
Cc: [email protected]
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
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan

Reply via email to