[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
Thu Jun 23 07:55:52 EDT 2016
hi nick,
As you mentioned I add leftsourceip = localprivateip, and captured data
on ONT1's wan interface:
08:49:40.752859 IP 135.251.199.83 > 135.251.205.188:
ESP(spi=0x9562ea8a,seq=0x18), length 100
08:49:40.754909 IP 135.251.205.188 > 135.251.199.83:
ESP(spi=0x14d1c2dd,seq=0x18), length 100
08:49:40.755230 IP 192.168.5.100 > 192.168.1.101: ICMP echo reply, id 1,
seq 408, length 40
I issue a ping from 192.168.1.101 to 192.168.5.100 and have saw a ICMP
echo replay.
It's closer to achievement. The last step is forward this echo reply to my
PC1.
Should iptables rule can do this? or ONT1 lack of function?
I am very looking forward to your response! thank you very much again!
On 23 June 2016 at 15:07, Nick Howitt <nick at howitts.co.uk> wrote:
> Replying to the list as well - please can you.
>
> That is by and large an l2tp set-up. If you don't want an l2tp set-up,
> remove the protoport. I'd also remove left/rightid. Is right
> 135.251.199.83 or dynamic? If it is 135.251.199.83 don't use %any, use
> the IP. If it is dynamic, make sure you have %any in ipsec secrets.
>
> To allow server-server comms you need to specify left/rightsourceip in the
> local conn (so leftsourceip on the left machine) specifying the remote's
> source IP is OK to give you a portable conn but otherwise achieves nothing.
>
> On 23/06/2016 07:20, xue tao 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
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20160623/b7958846/attachment-0001.html>
More information about the Users
mailing list