[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
xue tao
xuetao325 at gmail.com
Tue Jun 28 23:48:24 EDT 2016
hi,nick
Good news is I made it. I used transport mode and not added subnet
configuration in ipsec.conf. Maybe I misunderstood this topology. My ONT1
nat packets on interface ppp0 then I should think ONT1 as a pc client. when
this transport mode tunnel setup I add a route: route add -net
192.168.5.0/24 ppp0. As a result my pc ipaddr was nated to ppp0 ipaddr
192.168.3.128 and the source ip of packets captured ont ONT2's ppp0
interface also was 192.168.3.128. Between ONT1 and ONT2 we only get ESP
packets.so that's it. netkey with l2tp/ipsec.
Compare with your route and xfrm policy I can tell anything different
from mine. Maybe I can't follow your topology. And subnet-to-subnet mode is
still on my way. I will continue read openswan code and try to solve it.
thank you very much again!
On 24 June 2016 at 20:47, Nick Howitt <nick at howitts.co.uk> wrote:
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20160629/412a5a03/attachment-0001.html>
More information about the Users
mailing list