[Swan] Does libreswan v3.20 support multiple clients behind NAT to communicate with public server simultaneously?
Paul Wouters
paul at nohats.ca
Tue Oct 31 18:34:42 UTC 2017
Do not run any iptables yourself!
Configure mark=-1/0xfffffffff in your ipsec configuration. Libreswan will add/remove the iptables rules
Sent from my iPhone
> On Oct 31, 2017, at 21:08, Hao Chen <earthlovepython at outlook.com> wrote:
>
> Hi Paul / All:
>
>
>
> Everyone, happy Halloween!
>
>
>
> 1.
>
> Appreciate for your response at first.
>
>
>
> 2.
>
> If I understand your point correctly, I applied following "iptables rules" on public server side. But still no luck.
>
>
> iptables -t mangle -I PREROUTING -m policy --dir in --pol IPsec -j MARK --set-mark 0xffffffff
> iptables -t mangle -I POSTROUTING -m policy --dir out --pol IPsec -j MARK --set-mark 0xffffffff
>
>
>
> OR
>
>
>
> iptables -t mangle -I PREROUTING -m policy --dir in -p ESP -j MARK --set-mark 0xffffffff
>
> iptables -t mangle -I POSTROUTING -m policy --dir out -p ESP -j MARK --set-mark 0xffffffff
>
>
>
>
>
> Why I put "0xffffffff" instead of "-1" ? iptables report error "bad mark value for option "--set-mark", or out of range"
>
>
> (By the way, I also tried "-j CONNMARK --set-mark 0xffffffff". still not work.)
>
>
> Is above command correct? Did I misunderstand your instruction?
>
>
> 3.
>
> 1). After I start 1st private client behind NAT, "ip xfrm pol" on public server shows:
>
>
> src 10.0.146.196/32 dst 192.168.161.0/24
> dir out priority 2088 ptype main
> tmpl src 10.0.146.196 dst 10.0.161.34
> proto esp reqid 16397 mode tunnel
> src 192.168.161.0/24 dst 10.0.146.196/32
> dir fwd priority 2088 ptype main
> tmpl src 10.0.161.34 dst 10.0.146.196
> proto esp reqid 16397 mode tunnel
> src 192.168.161.0/24 dst 10.0.146.196/32
> dir in priority 2088 ptype main
> tmpl src 10.0.161.34 dst 10.0.146.196
> proto esp reqid 16397 mode tunnel
>
> 2). After I start 2nd private client behind NAT, "ip xfrm pol" on public server shows:
>
> src 10.0.146.196/32 dst 192.168.161.0/24
> dir out priority 2088 ptype main
> tmpl src 10.0.146.196 dst 10.0.161.34
> proto esp reqid 16401 mode tunnel
> src 192.168.161.0/24 dst 10.0.146.196/32
> dir fwd priority 2088 ptype main
> tmpl src 10.0.161.34 dst 10.0.146.196
> proto esp reqid 16401 mode tunnel
> src 192.168.161.0/24 dst 10.0.146.196/32
> dir in priority 2088 ptype main
> tmpl src 10.0.161.34 dst 10.0.146.196
> proto esp reqid 16401 mode tunnel
>
> 3). After I start 2nd private client behind NAT, "ip xfrm state" on public server shows:
>
> [root at xcvms196 configs]# ip x s
> src 10.0.161.34 dst 10.0.146.196
> proto esp spi 0x7c64a8c0 reqid 16401 mode tunnel
> replay-window 32 flag af-unspec
> auth-trunc hmac(md5) 0x4bcfde9f974a8687e4e3ef13099d47b0 96
> enc cbc(des3_ede) 0x7bf36fe75db23faba9ab4988e5a8f0d078700f84e9d2f1ba
> encap type espinudp sport 40004 dport 4500 addr 0.0.0.0
> anti-replay context: seq 0xad, oseq 0x0, bitmap 0xffffffff
> src 10.0.146.196 dst 10.0.161.34
> proto esp spi 0x861c7bfa reqid 16401 mode tunnel
> replay-window 32 flag af-unspec
> auth-trunc hmac(md5) 0x11a031caa1d3275b711cdb0233fb3b89 96
> enc cbc(des3_ede) 0xd3bad85755cbfbcf8c52c781be0b097efc977c29d9a6394d
> encap type espinudp sport 4500 dport 40004 addr 0.0.0.0
> anti-replay context: seq 0x0, oseq 0xad, bitmap 0x00000000
> src 10.0.146.196 dst 192.168.161.44
> proto esp spi 0x00000000 reqid 0 mode transport
> replay-window 0
> anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
> sel src 10.0.146.196/32 dst 192.168.161.44/32 proto icmp type 0 code 0 dev eth0
> src 10.0.161.34 dst 10.0.146.196
> proto esp spi 0x8814c900 reqid 16397 mode tunnel
> replay-window 32 flag af-unspec
> auth-trunc hmac(md5) 0x51139bef3e2844a9f5f5be76168f9bf7 96
> enc cbc(des3_ede) 0x93bfd2ffedce31eca6060300395cc463cb0afa8f4f690947
> encap type espinudp sport 40003 dport 4500 addr 0.0.0.0
> anti-replay context: seq 0xca, oseq 0x0, bitmap 0xffffffff
> src 10.0.146.196 dst 10.0.161.34
> proto esp spi 0xa112d396 reqid 16397 mode tunnel
> replay-window 32 flag af-unspec
> auth-trunc hmac(md5) 0xcc17a8448aac4c46520497a80c80cec8 96
> enc cbc(des3_ede) 0x98ecc800d52aed60080cfc6e6de8a9f2dbbb8299437c34bf
> encap type espinudp sport 4500 dport 40003 addr 0.0.0.0
> anti-replay context: seq 0x0, oseq 0x1b, bitmap 0x00000000
>
> ====> From above "ip xfrm pol" output, I do not see "mark" this column.
>
>
>
> 4.
> "ip" version is : "ip utility, iproute2-ss130716"
> "iptables" version is: "iptables v1.4.21"
> uname shows: "Linux xcvms196 3.10.0-693.el7.x86_64 #1 SMP Thu Jul 6 19:56:57 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux"
>
>
>
> Thanks and regards
>
> Hao Chen
>
>
> From: Paul Wouters <paul at nohats.ca>
> Sent: Monday, October 30, 2017 23:45
> 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 Tue, 31 Oct 2017, Hao Chen wrote:
>
> > I still cannot let 2 private clients behind NAT to communicate public server simultaneous. Can you please help me?
>
> Did you try the -1 mark that causes unique marks in the XFRM policy per
> client, with overlapip=yes set? It should need no custom iptables
> rules. That should work. If not, you should let us now what specific
> errors or problems you are seeing.
>
> The reqids should then also automatically get generated and be unique
> per client. Setting them manually is almost never the right solution.
>
> All of this only needs to happen on the server side. The client side
> needs no marking or anything odd, because it has no conflicts itself.
>
> Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20171031/46d6adf8/attachment-0001.html>
More information about the Swan
mailing list