[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 07:50:15 EDT 2016 

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 [3] -j
> MASQUERADE
>    ---> iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.1.0/24 [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] 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]
> 
> oops, the ping packets has no response.
> 
> step 3:
>   Add the new iptables:
>     iptables -t nat -A POSTROUTING -s 192.168.1.0/24 [3] -d
> 192.168.5.0/24 [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
> [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 [1]
>>> <http://192.168.1.0/255.255.255.0 [1]>
>>> <http://192.168.1.0/255.255.255.0 [1]> -j MASQUERADE
>>> iptables -t nat -D POSTROUTING -o eth4 -s
>>> 192.168.1.0/255.255.255.0 [1]
>>> <http://192.168.1.0/255.255.255.0 [1]>
>>> <http://192.168.1.0/255.255.255.0 [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]
>>> <http://192.168.5.0/24 [2]> <http://192.168.5.0/24 [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 [3]
>>> <http://192.168.1.0/24 [3]>
>>> <http://192.168.1.0/24 [3]>
>>> <http://192.168.1.0/24 [3]> private subnet
>>> 192.168.5.0/24 [2]
>>> <http://192.168.5.0/24 [2]>
>>> <http://192.168.5.0/24 [2]>
>>> <http://192.168.5.0/24 [2]>
>>> PC1 ------ ONT1 <========IPSEC
>>> TUNNEL=========>
>>> ONT2 ------- PC2
>>> 135.251.199.83 [4] <tel:135.251.199.83 [4]>
>>> <tel:135.251.199.83 [4]
>>> <tel:135.251.199.83 [4]>> 135.251.205.188
>>> 
>>> 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 [3] <http://192.168.1.0/24
>>> [3]>
>>> <http://192.168.1.0/24 [3]>
>>> <http://192.168.1.0/24 [3]> dst 192.168.5.0/24
>>> [2]
>>> <http://192.168.5.0/24 [2]>
>>> <http://192.168.5.0/24 [2]>
>>> <http://192.168.5.0/24 [2]> proto udp
>>> sport 1701 dport 1701
>>> dir out priority 2344
>>> tmpl src 135.251.199.83 [4]
>>> <tel:135.251.199.83 [4]>
>>> <tel:135.251.199.83 [4] <tel:135.251.199.83 [4]>> dst
>>> 135.251.205.188
>>> proto esp reqid 16385 mode tunnel
>>> src 192.168.5.0/24 [2] <http://192.168.5.0/24
>>> [2]>
>>> <http://192.168.5.0/24 [2]>
>>> <http://192.168.5.0/24 [2]> dst 192.168.1.0/24
>>> [3]
>>> <http://192.168.1.0/24 [3]>
>>> <http://192.168.1.0/24 [3]>
>>> <http://192.168.1.0/24 [3]> proto udp
>>> sport 1701 dport 1701
>>> dir fwd priority 2344
>>> tmpl src 135.251.205.188 dst 135.251.199.83
>>> [4]
>>> <tel:135.251.199.83 [4]>
>>> <tel:135.251.199.83 [4] <tel:135.251.199.83 [4]>>
>>> proto esp reqid 16385 mode tunnel
>>> src 192.168.5.0/24 [2] <http://192.168.5.0/24
>>> [2]>
>>> <http://192.168.5.0/24 [2]>
>>> <http://192.168.5.0/24 [2]> dst 192.168.1.0/24
>>> [3]
>>> <http://192.168.1.0/24 [3]>
>>> <http://192.168.1.0/24 [3]>
>>> <http://192.168.1.0/24 [3]> proto udp
>>> sport 1701 dport 1701
>>> 
>>> dir in priority 2344
>>> tmpl src 135.251.205.188 dst 135.251.199.83
>>> [4]
>>> <tel:135.251.199.83 [4]>
>>> <tel:135.251.199.83 [4] <tel:135.251.199.83 [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 [4] <tel:135.251.199.83
>>> [4]>
>>> <tel:135.251.199.83 [4] <tel:135.251.199.83 [4]>>
>>> 
>>> leftnexthop=%defaultroute
>>> leftprotoport=17/1701
>>> leftsubnet=192.168.1.0/24 [3]
>>> <http://192.168.1.0/24 [3]>
>>> <http://192.168.1.0/24 [3]>
>>> <http://192.168.1.0/24 [3]>
>>> right=135.251.205.188
>>> rightprotoport=17/1701
>>> rightsubnet=192.168.5.0/24 [2]
>>> <http://192.168.5.0/24 [2]>
>>> <http://192.168.5.0/24 [2]>
>>> <http://192.168.5.0/24 [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]
>>> <http://192.168.5.0/24 [2]> <http://192.168.5.0/24 [2]>
>>> <http://192.168.5.0/24 [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 [5]
>>> Micropayments:
>>> https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
>>> [6]
>>> Building and Integrating Virtual Private Networks
>>> with
>>> Openswan:
>>> 
>>> 
>> 
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>>> [7]
> 
> 
> 
> Links:
> ------
> [1] http://192.168.1.0/255.255.255.0
> [2] http://192.168.5.0/24
> [3] http://192.168.1.0/24
> [4] tel:135.251.199.83
> [5] https://lists.openswan.org/mailman/listinfo/users
> [6] https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> [7] 
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
> [8]
> http://serverfault.com/questions/635012/why-are-only-3-ip-xfrm-policies-needed-for-a-ipsec-tunnel

More information about the Users mailing list