[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
Wed Jun 22 11:36:23 EDT 2016 

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> 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 [1]
>> [3] -j
>>> MASQUERADE
>>> ---> iptables -t nat -A POSTROUTING -o ppp0 -s 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 [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 [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 [1] [3] -d
>>> 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> 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>> 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 [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 [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 [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>>> 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 [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 [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 [5] [4] <tel:135.251.199.83 [5] [4]>
>>>>> <tel:135.251.199.83 [5] [4]
>>>>> <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 [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 [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 [5] [4]
>>>>> <tel:135.251.199.83 [5] [4]>
>>>>> <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 [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 [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 [5] [4]>
>>>>> <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 [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 [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 [5] [4]>
>>>>> <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 [5] [4] <tel:135.251.199.83 [5]
>>>>> [4]>
>>>>> <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 [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 [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 [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>>
>>>>> 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 [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