[Openswan Users] Move to Inbox More 1 of 65 [openswan users] I have some problem about ping from pc1 to pc2 in vpn site2site tunnel mode.thanks
Nick Howitt
nick at howitts.co.uk
Fri Jun 24 08:47:48 EDT 2016
Please can you reply on-list although there may be some mailing problems
as I received a bounce today.
My set up is Libreswan, not Openswan and the remote end is a commercial
router with its proprietary solution but Libreswan should give very
similar results:
[root at server ~]# ip ro
10.8.10.2 dev tun1 proto kernel scope link src 10.8.10.1
10.8.0.2 dev tun2 proto kernel scope link src 10.8.0.1
172.17.3.2 dev tun0 proto kernel scope link src 172.17.3.1
10.8.0.0/24 via 10.8.0.2 dev tun2
82.19.158.0/24 dev eth0 proto kernel scope link src 82.19.158.192
192.168.30.0/24 via 82.19.158.1 dev eth0 src 172.17.2.1
10.8.10.0/24 via 10.8.10.2 dev tun1
172.17.2.0/24 dev eth1 proto kernel scope link src 172.17.2.1
172.17.3.0/24 via 172.17.3.2 dev tun0
239.0.0.0/8 dev eth1 scope link
default via 82.19.158.1 dev eth0
But to a large extent the routing table is not used. My local LAN(s) are
172.17.2.0/24 and 172.17.3.0/24. Ignore 10.8.x.y (OpenVPN) and the main
OpenVPN subnet 172.17.3.0/24. The remote VON subnet is 192.168.30.0/24.
Perhaps more important is the xfrm policy and state but I am not sure
how to read them:
[root at server ~]# ip xfrm state
src 82.19.158.192 dst 89.242.219.76
proto esp spi 0xbe89750a reqid 16389 mode tunnel
replay-window 32 flag 20
auth hmac(sha1) 0x600ba5a84c897158ce7c74f69270e36f5ffa9254
enc cbc(aes)
0x2cfd3d7f2c7bd0b3f05d8d463362abcae8ca2fdc30d3a8a0894f8aaa5ffc32b6
src 89.242.219.76 dst 82.19.158.192
proto esp spi 0xbeaa4323 reqid 16389 mode tunnel
replay-window 32 flag 20
auth hmac(sha1) 0xcee1f9cf67e618eb1a83f74dda20bd281ed9b3e0
enc cbc(aes)
0xcb538cc2fec416f68556ea2bc68e8b6fb2a6edbb80b4dc58da9105df9ce587d0
src 82.19.158.192 dst 89.242.219.76
proto esp spi 0xbe897509 reqid 16389 mode tunnel
replay-window 32 flag 20
auth hmac(sha1) 0x0c377b013d79493149f50263b2bc1dbfc0b53063
enc cbc(aes)
0xd6ae0f08a48d904e65fab38d5ea82e9b466d3af093f5d41260d7d5aff3bb36e3
src 89.242.219.76 dst 82.19.158.192
proto esp spi 0xa1e23c36 reqid 16389 mode tunnel
replay-window 32 flag 20
auth hmac(sha1) 0xbb40c1627a4b362075d51cf9df875db92aa391c2
enc cbc(aes)
0x5fe32fb4c2a4293f0d953b51cf23ee3d81f79781678705353aa6364abf8c0887
and
[root at server ~]# ip xfrm policy
src 172.17.2.0/24 dst 192.168.30.0/24
dir out priority 2344 ptype main
tmpl src 82.19.158.192 dst 89.242.219.76
proto esp reqid 16389 mode tunnel
src 192.168.30.0/24 dst 172.17.2.0/24
dir fwd priority 2344 ptype main
tmpl src 89.242.219.76 dst 82.19.158.192
proto esp reqid 16389 mode tunnel
src 192.168.30.0/24 dst 172.17.2.0/24
dir in priority 2344 ptype main
tmpl src 89.242.219.76 dst 82.19.158.192
proto esp reqid 16389 mode tunnel
........snipped to the end
When you do a tcpdump you can specify the interface but it is not a tool
I use.
To check if the tunnel is up, look at /var/log/messages for a pluto
message with something like "IPsec SA established".
Then ping from the console of ONT1 to the LAN IP of ONT2. If that works
then ping to the remote subnet and so on. Also check the device you are
pinging on the remote subnet is not firewalled from your local subnet.
Window's firewall often only allows access from machines on its local
subnet only
On 24/06/2016 11:25, xue tao wrote:
> It's none sense of vlan tag. And a interesting thing is that the
> captured ICMP reply packets has dst ip with PC1(192.168.1.101) but dst
> mac with ONT1 wan interface mac.
> Can you show me your route on equipment like ONT1 and ONT2. Now i was
> doubt everything, nothing was confirmed :(
>
> On 24 June 2016 at 15:13, xue tao <xuetao325 at gmail.com
> <mailto:xuetao325 at gmail.com>> wrote:
>
> hi,
> sorry for cut old messages. ONT1 is gateway of 192.168.1.x and
> ONT2 of 192.168.5.x. My workmates told me maybe some vlan impact
> network and drop the packets. I was checking it.
>
> pc1(eth0:192.168.1.100) <------------> (eth1:192.168.1.1)
> ONT1
> (eth0:135.251.199.83)
> <=======VPN TUNNEL========>
> ONT2 (eth0:135.251.205.188)
> (eth1:192.168.5.1) <----------->(eht0:192.168.5.100)pc2
>
>
> On 23 June 2016 at 14:20, xue tao <xuetao325 at gmail.com
> <mailto:xuetao325 at gmail.com>> wrote:
>
> hi,
> This is my environment, when site2site tunnel up we found
> ppp0 on each end. ONT2 is vpn server.
> pc1(eth0:192.168.1.100) <------------> (eth1:192.168.1.1)
> ONT1 (eth0:135.251.199.83)
> (ppp0:192.168.3.128)
> <=======VPN TUNNEL========>
> (ppp0:192.168.3.1)
> ONT2 (eth0:135.251.205.188)
> (eth1:192.168.5.1) <----------->(eht0:192.168.5.100)pc2
>
> Here is ONT1 ipsec.conf:
> [root at AONT: admin]# cat /etc/ipsec.conf
> version 2.0 # conforms to second version of ipsec.conf
> specification
> config setup
> nat_traversal=yes
> oe=off
> protostack=netkey
> plutostderrlog=/tmp/vpnerr.log
> plutoopts="--interface=eth0"
> conn L2TP-PSK
> authby=secret
> pfs=no
> auto=add
> keyingtries=3
> dpddelay=30
> dpdtimeout=120
> dpdaction=Restart
> rekey=yes
> ikelifetime=8h
> keylife=1h
> type=tunnel
> left=135.251.199.83
> leftnexthop=%defaultroute
> leftprotoport=17/1701
> leftsubnet=192.168.1.0/24 <http://192.168.1.0/24>
> right=135.251.205.188
> rightprotoport=17/1701
> rightsubnet=192.168.5.0/24 <http://192.168.5.0/24>
>
> And this is ONT2's:
> conn L2TP-PSK-NAT
> rightsubnet=vhost:%priv
> also=L2TP-PSK-noNAT
>
> conn L2TP-PSK
> authby=secret
> pfs=no
> keyingtries=3
> dpddelay=30
> dpdtimeout=120
> dpdaction=clear
> rekey=yes
> ikelifetime=8h
> keylife=8h
> type=tunnel
> # Replace %any below with your local IP address (private,
> behind NAT IP is okay as well)
> left=135.251.205.188
> leftsubnet=192.168.5.0/24 <http://192.168.5.0/24>
> #leftnexthop=%defaultroute
> leftid=135.251.205.188
> leftprotoport=17/1701
> # Replace IP address with your VPN server's IP
> right=%any
> rightsubnet=192.168.1.0/24 <http://192.168.1.0/24>
> rightid=135.251.199.83
> rightprotoport=17/1701
> auto=add
>
> When the tunnel setup, I check route on ONT1:
> [root at AONT: vtadmin]# route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref
> Use Iface
> 0.0.0.0 135.251.196.1 0.0.0.0 UG 0
> 0 0 eth0
> 135.251.196.0 0.0.0.0 255.255.252.0 U 0 0
> 0 eht0
> 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0
> 0 eht1
> 192.168.3.1 0.0.0.0 255.255.255.255 UH 0 0
> 0 ppp0
>
> There is no route to 192.168.5.0/24 <http://192.168.5.0/24>,
> maybe it is the reason I can't ping from pc1 to pc2?
>
> Another situation is when setup end2end tunnel I capture esp
> ping packet from ONT1 to ONT2; and when setup site2site tunnel
> I only capture plain text ping packet from ONT1 to ONT2, is
> this correct?
>
>
>
> On 22 June 2016 at 23:36, Nick Howitt <nick at howitts.co.uk
> <mailto:nick at howitts.co.uk>> wrote:
>
> Can you the post your updated ipsec.conf?
>
> On 2016-06-22 16:19, xuetao325 wrote:
>
> It's none sense of l2tp configuration. I was also
> connected
> subnet/subnet with netkey/psk. I just wonder which
> iptables rules will
> needed except ones auto-configed by openswan. In my
> opinion last month
> it shoud works fine after modifed ipsec.conf :)
>
> Sent from my Mi phone
> On Jun 22, 2016 7:50 PM, Nick Howitt
> <nick at howitts.co.uk <mailto:nick at howitts.co.uk>> wrote:
>
> Sorry, but I was only trying to sort out the basic
> firewalling which
> was
> needed. I know nothing about L2TP configurations, only
> subnet/subnet
> with netkey/psk, so I can't take you an further.
>
> Nick
>
> On 2016-06-22 12:25, xue tao wrote:
>
> hi nick,
> I load xt_policy success and try some iptables
> and route below,
>
> it
>
> does not works yet.
>
> step 1:
> When vpn tunnel setup, I changed iptables
> about "-o " from eth4
>
> to
>
> ppp0 on ONT1:
> iptables -t nat -A POSTROUTING -o eth4 -s
> 192.168.1.0/24 <http://192.168.1.0/24> [1]
>
> [3] -j
>
> MASQUERADE
> ---> iptables -t nat -A POSTROUTING -o ppp0 -s
> 192.168.1.0/24 <http://192.168.1.0/24>
>
> [1] [3]
>
> -j MASQUERADE
>
> This step was reserve from end-to-end
> transport mode. In
>
> end-to-end I
>
> can ping from PC1 to ONT2(vpn server) as this
> iptables rule
>
> changes.
>
>
> step 2:
> So I add farside subnet via ppp0 route :
> route add -net 192.168.5.0/24
> <http://192.168.5.0/24> [2] [2] ppp0
>
> Then PC1 can ping PC2 but the packets was
> plain text, not ESP
> packets.this time I load xt_policy and added
> iptables :
> iptables -t nat -I POSTROUTING -m policy --dir
> out --pol ipsec
>
> -j
>
> ACCEPT
>
> The ping packets I dump from ONT2 still plain.
> then I think the
> route maybe wrong,so:
> route del -net 192.168.5.0/24
> <http://192.168.5.0/24> [2] [2]
>
> oops, the ping packets has no response.
>
> step 3:
> Add the new iptables:
> iptables -t nat -A POSTROUTING -s
> 192.168.1.0/24 <http://192.168.1.0/24> [1] [3] -d
> 192.168.5.0/24 <http://192.168.5.0/24> [2] [2]
> -j ACCEPT
>
> No response,
> After I delete iptables -t nat -D POSTROUTING
> -m policy --dir
>
> out
>
> --pol ipsec -j ACCEPT. ping still has no response.
>
> Should I miss some iptables rules? or other
> aspects like config
>
> file,
>
> the environment or topology? from this issue
>
>
> http://serverfault.com/questions/635012/why-are-only-3-ip-xfrm-policies-needed-for-a-ipsec-tunnel
>
> [3]
>
> [8]
>
> It seem xfrm policy is ok. I am so confuse
> with subnet2subnet and
> don't know how to check it?
>
> On 21 June 2016 at 21:09, Nick Howitt
> <nick at howitts.co.uk
> <mailto:nick at howitts.co.uk>> wrote:
>
> Actually you can use your original
> iptables rule but just change
>
> "-j
>
> SNAT --to site-A-Public-IP" to "-j
> ACCEPT". I prefer the policy
> approach as you don't need to specify the
> subnets but either
>
> should
>
> work.
>
> On 21/06/2016 10:31, xue tao wrote:
>
> hi
> I have check
> ./net/netfilter/xt_policy.c, there is
> no object
> file. so I add
> CONFIG_NETFILTER_XT_MATCH_POLICY into
> kernel
> config and xt_policy.c will be make.
> Now i was compiling the image and
> examine it later. Hope this
> mod will be load success. I will be in
> touch with you. thanks!
>
> On 21 June 2016 at 16:08, Nick Howitt
> <nick at howitts.co.uk
> <mailto:nick at howitts.co.uk>
> <mailto:nick at howitts.co.uk
> <mailto:nick at howitts.co.uk>>> wrote:
>
> I'd be very surprised if the target
> ACCEPT did not exist but
> have
> no idea how to check. It should be one
> of the iptables
> default
> targets. Can you check the policy
> module is loaded: "lsmod |
> grep
> policy"? It should return something
> with "xt_policy" in it.
> If it
> does not, please do a "modprobe
> xt_policy" then try the
> iptables
> rule again.
>
> On 21/06/2016 08:51, xue tao wrote:
>
> hi nickļ¼
> I'm very glad to see your response. I
> type this
> iptables
> command into ONT1:
> [root at AONT: admin]# iptables -t nat -I
> POSTROUTING -m
> policy --dir out --pol ipsec -j ACCEPT
> iptables: No chain/target/match by
> that name.
>
> This maybe lack of several kernel
> configuration. so I
> turn
> on some kernel config about
> IPSEC/ESP/AH and so on. but
> this
> prompt still exist.
> The attachment is my kernel
> configuration about
> netfilter.
> Please let me know if i was in wrong
> road.thanks very
> much.
> # Core Netfilter Configuration
> CONFIG_NF_CT_PROTO_ESP=y
> CONFIG_NF_CONNTRACK_IPSEC=y
> # Xtables matches
> CONFIG_NETFILTER_XT_MATCH_ESP=y
> CONFIG_NF_CONNTRACK_IPSEC=y
> # IP: Netfilter Configuration
> CONFIG_IP_NF_MATCH_AH=y
> CONFIG_NF_NAT_IPSEC=y
>
> In the end to end mode, I deply this
> commands and it work
> iptables -t nat -A POSTROUTING -o ppp0 -s
> 192.168.1.0/255.255.255.0
> <http://192.168.1.0/255.255.255.0> [4] [1]
> <http://192.168.1.0/255.255.255.0 [4] [1]>
> <http://192.168.1.0/255.255.255.0 [4]
> [1]> -j MASQUERADE
> iptables -t nat -D POSTROUTING -o eth4 -s
> 192.168.1.0/255.255.255.0
> <http://192.168.1.0/255.255.255.0> [4] [1]
> <http://192.168.1.0/255.255.255.0 [4] [1]>
> <http://192.168.1.0/255.255.255.0 [4]
> [1]> -j MASQUERADE
>
> so I reserve this commands in site to
> site mode. and all
> my
> iptables command is only this two.
> I don't know whether impacts our packets.
>
> another questions is:
> From command (ip xfrm policy) i found
> that dir in/dir
> out/dir
> forward were assigned properly, Is
> this not enough for
> issuing
> a ping from PC1 to PC2?
> is this command(route add -net
> 192.168.5.0/24 <http://192.168.5.0/24>
> [2] [2]
> <http://192.168.5.0/24 [2] [2]>
> <http://192.168.5.0/24 [2] [2]>
> ppp0) necessary? i think this route
> make packet forwarding
> on l2tp
> tunnel directly instead of vpn tunnel.
>
> On 20 June 2016 at 23:25, Nick Howitt
> <nick at howitts.co.uk
> <mailto:nick at howitts.co.uk>
> <mailto:nick at howitts.co.uk
> <mailto:nick at howitts.co.uk>>
> <mailto:nick at howitts.co.uk
> <mailto:nick at howitts.co.uk>
> <mailto:nick at howitts.co.uk
> <mailto:nick at howitts.co.uk>>>> wrote:
>
> I would not SNAT traffic unless
> specifically
> required. Try:
>
> iptables -t nat -I POSTROUTING -m
> policy --dir out
> --pol ipsec
> -j ACCEPT
>
> Nick
>
> On 20/06/2016 13:48, xue tao wrote:
>
> Hi,
> my network configurationis :
>
> private subnet 192.168.1.0/24
> <http://192.168.1.0/24> [1] [3]
> <http://192.168.1.0/24 [1] [3]>
> <http://192.168.1.0/24 [1] [3]>
> <http://192.168.1.0/24 [1] [3]>
> private subnet
> 192.168.5.0/24 <http://192.168.5.0/24>
> [2] [2]
> <http://192.168.5.0/24 [2] [2]>
> <http://192.168.5.0/24 [2] [2]>
> <http://192.168.5.0/24 [2] [2]>
> PC1 ------ ONT1 <========IPSEC
> TUNNEL=========>
> ONT2 ------- PC2
> 135.251.199.83
> <tel:135.251.199.83> [5] [4]
> <tel:135.251.199.83 [5] [4]>
> <tel:135.251.199.83
> <tel:135.251.199.83> [5] [4]
> <tel:135.251.199.83
> <tel:135.251.199.83> [5] [4]>>
> 135.251.205.188 [6]
>
> i am setting up a ipsec tunnel on ONT1
> and ONT2,
> and this
> tunnel seems had setup, on ONT1 i can saw:
>
> [root at AONT: admin]# ipsec --version
> Linux Openswan U2.6.38/K3.4.11-rt19
> (netkey)
>
> [root at AONT: admin]# ipsec setup status
> IPsec running - pluto pid: 6676
> pluto pid 6676
> 1 tunnels up
> some eroutes exist
>
> [root at AONT: admin]# ip xfrm policy
> src 192.168.1.0/24
> <http://192.168.1.0/24> [1] [3]
> <http://192.168.1.0/24 [1]
> [3]>
> <http://192.168.1.0/24 [1] [3]>
> <http://192.168.1.0/24 [1] [3]> dst
> 192.168.5.0/24 <http://192.168.5.0/24> [2]
> [2]
> <http://192.168.5.0/24 [2] [2]>
> <http://192.168.5.0/24 [2] [2]>
> <http://192.168.5.0/24 [2] [2]> proto udp
> sport 1701 dport 1701
> dir out priority 2344
> tmpl src 135.251.199.83
> <tel:135.251.199.83> [5] [4]
> <tel:135.251.199.83
> <tel:135.251.199.83> [5] [4]>
> <tel:135.251.199.83
> <tel:135.251.199.83> [5] [4]
> <tel:135.251.199.83 [5] [4]>> dst
> 135.251.205.188 [6]
> proto esp reqid 16385 mode tunnel
> src 192.168.5.0/24
> <http://192.168.5.0/24> [2] [2]
> <http://192.168.5.0/24 [2]
> [2]>
> <http://192.168.5.0/24 [2] [2]>
> <http://192.168.5.0/24 [2] [2]> dst
> 192.168.1.0/24 <http://192.168.1.0/24> [1]
> [3]
> <http://192.168.1.0/24 [1] [3]>
> <http://192.168.1.0/24 [1] [3]>
> <http://192.168.1.0/24 [1] [3]> proto udp
> sport 1701 dport 1701
> dir fwd priority 2344
> tmpl src 135.251.205.188 [6] dst
> 135.251.199.83 [5]
> [4]
> <tel:135.251.199.83
> <tel:135.251.199.83> [5] [4]>
> <tel:135.251.199.83
> <tel:135.251.199.83> [5] [4]
> <tel:135.251.199.83 [5] [4]>>
> proto esp reqid 16385 mode tunnel
> src 192.168.5.0/24
> <http://192.168.5.0/24> [2] [2]
> <http://192.168.5.0/24 [2]
> [2]>
> <http://192.168.5.0/24 [2] [2]>
> <http://192.168.5.0/24 [2] [2]> dst
> 192.168.1.0/24 <http://192.168.1.0/24> [1]
> [3]
> <http://192.168.1.0/24 [1] [3]>
> <http://192.168.1.0/24 [1] [3]>
> <http://192.168.1.0/24 [1] [3]> proto udp
> sport 1701 dport 1701
>
> dir in priority 2344
> tmpl src 135.251.205.188 [6] dst
> 135.251.199.83 [5]
> [4]
> <tel:135.251.199.83
> <tel:135.251.199.83> [5] [4]>
> <tel:135.251.199.83
> <tel:135.251.199.83> [5] [4]
> <tel:135.251.199.83 [5] [4]>>
>
>
> proto esp reqid 16385 mode tunnel
> src ::/0 dst ::/0
> socket out priority 0
>
> and here is my ipsec.conf
> version 2.0 # conforms to second
> version of
> ipsec.conf
> specification
> config setup
> nat_traversal=yes
> oe=off
> protostack=netkey
> plutostderrlog=/tmp/vpnerr.log
> plutoopts="--interface=eth4"
> conn L2TP-PSK
> authby=secret
> pfs=no
> auto=add
> keyingtries=3
> dpddelay=30
> dpdtimeout=120
> dpdaction=Restart
> rekey=yes
> ikelifetime=8h
> keylife=1h
> type=tunnel
> left=135.251.199.83
> <tel:135.251.199.83> [5] [4]
> <tel:135.251.199.83 [5]
> [4]>
> <tel:135.251.199.83
> <tel:135.251.199.83> [5] [4]
> <tel:135.251.199.83 [5] [4]>>
>
> leftnexthop=%defaultroute
> leftprotoport=17/1701
> leftsubnet=192.168.1.0/24
> <http://192.168.1.0/24> [1] [3]
> <http://192.168.1.0/24 [1] [3]>
> <http://192.168.1.0/24 [1] [3]>
> <http://192.168.1.0/24 [1] [3]>
> right=135.251.205.188 [6]
> rightprotoport=17/1701
> rightsubnet=192.168.5.0/24
> <http://192.168.5.0/24> [2] [2]
> <http://192.168.5.0/24 [2] [2]>
> <http://192.168.5.0/24 [2] [2]>
> <http://192.168.5.0/24 [2] [2]>
>
> Then I can not access to 192.168.5.x,
> and i
> follow some
> documents from internet adding
> iptables likes:
> iptables -t nat -A POSTROUTING -s
> site-A-private-subnet -d
> site-B-private-subnet -j SNAT --to
> site-A-Public-IP
>
> but it does not works. when i add
> route from my
> workmates:
> route add -net 192.168.5.0/24
> <http://192.168.5.0/24> [2] [2]
> <http://192.168.5.0/24 [2] [2]>
> <http://192.168.5.0/24 [2] [2]>
> <http://192.168.5.0/24 [2] [2]> ppp0
> I can ping 192.168.5.x ,but the
> tcpdump data on
> ONT2
> was not
> ESP, only ICMP packets. So this is not the
> correct ways.
>
> Should I add other iptables or route
> to allow PC1
> ping
> PC2?
> Any assistance will be greatly
> appreciated!
>
> _______________________________________________
> Users at lists.openswan.org
> <mailto:Users at lists.openswan.org>
> <mailto:Users at lists.openswan.org
> <mailto:Users at lists.openswan.org>>
> <mailto:Users at lists.openswan.org
> <mailto:Users at lists.openswan.org>
> <mailto:Users at lists.openswan.org
> <mailto:Users at lists.openswan.org>>>
> https://lists.openswan.org/mailman/listinfo/users
> [7] [5]
> Micropayments:
> https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> [8]
> [6]
> Building and Integrating Virtual
> Private Networks
> with
> Openswan:
>
>
>
>
>
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>
> [9]
>
> [7]
>
>
>
>
> Links:
> ------
> [1] http://192.168.1.0/255.255.255.0 [4]
> [2] http://192.168.5.0/24 [2]
> [3] http://192.168.1.0/24 [1]
> [4] tel:135.251.199.83 <tel:135.251.199.83> [5]
> [5]
> https://lists.openswan.org/mailman/listinfo/users
> [7]
> [6]
> https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> [8]
> [7]
>
>
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>
> [9]
>
> [8]
>
>
> http://serverfault.com/questions/635012/why-are-only-3-ip-xfrm-policies-needed-for-a-ipsec-tunnel
>
> [3]
>
>
>
> Links:
> ------
> [1] http://192.168.1.0/24
> [2] http://192.168.5.0/24
> [3]
> http://serverfault.com/questions/635012/why-are-only-3-ip-xfrm-policies-needed-for-a-ipsec-tunnel
> [4] http://192.168.1.0/255.255.255.0
> [5] http://135.251.199.83
> [6] http://135.251.205.188
> [7] https://lists.openswan.org/mailman/listinfo/users
> [8]
> https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> [9]
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>
>
>
>
More information about the Users
mailing list