You are not logged in.
Hello all,
Why we need to at add routes manually after successful connection? if we compare it with PPTP SSTP they don't require manually entry, they do it their self.
Hope any one can answer it quickly.
Offline
Have you looked at leftsubnets, rightsubnets in the configuration file (man ipsec.conf)
Offline
Thanks for the reply, Below is our configuration file, i have properly configured both options, anything i am doing wrong here?
conn l2tp
authby=secret
keyexchange=ikev1
keyingtries=1
auto=add
dpdaction=clear
dpddelay=300s
type=transport
ike=3des-sha1-modp1024
left=%defaultroute
leftprotoport=17/1701
right=$SERVER
rightid=%any
rightprotoport=17/1701
leftnexthop=%defaultroute
rightnexthop=%defaultroute
Offline
Hi, either the configuration you've shared is incomplete,
or I've failed to find the leftsubnet(s), rightsubnet(s) statements.
You can test with appending the following bits to your config:
leftsubnet=<localnet1>
rightsubnet=<remotenet1>
or if you have multiple subnets on either side of the connection:
leftsubnets={<localnet1>,<localnet2>}
rightsubnets={<remotenet1>,<remotenet2>,<remotenet3>}
Just make sure you lways use both statements of the same type - singular or plural.
When connection is established successfully, you should be able to verify with:
ip xfrm state
ip xfrm policy
Offline
Thanks for the reply,
if i use leftsubnets and rightsubnets, i receive below error,
IKE_SA l2tp[1] established between 172.18.0.2[172.18.0.2]...vpnserverip[vpnserverip]
scheduling reauthentication in 10155s
maximum IKE_SA lifetime 10695s
DPD not supported by peer, disabled
local traffic selector missing in configuration
establishing connection 'l2tp' failed
output without above options,
$ ip xfrm state
src 172.18.0.2 dst vpnserverip
proto esp spi 0xd22294ab reqid 1 mode transport
replay-window 32
auth-trunc hmac(sha1) 0x539a7ecc12c8f8af2642041c1886a1a24fb1bb31 96
enc cbc(aes) 0x692ad71cbe77a198551a3d27d23bf0a9
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x2c, bitmap 0x00000000
sel src 172.18.0.2/32 dst vpnserverip/32
src vpnserverip dst 172.18.0.2
proto esp spi 0xcf38dcb0 reqid 1 mode transport
replay-window 32
auth-trunc hmac(sha1) 0x69a790ad48b1bdeea75784be83af26a2257cc5d5 96
enc cbc(aes) 0xce8293eb907b1d293b66b800ef494568
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0xdc, oseq 0x0, bitmap 0xf7fbefff
sel src vpnserverip/32 dst 172.18.0.2/32
$ ip xfrm policy
src vpnserverip/32 dst 172.18.0.2/32 proto 17 sport 1701 dport 1701
dir in priority 2816
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 1 mode transport
src 172.18.0.2/32 dst vpnserverip/32 proto 17 sport 1701 dport 1701
dir out priority 2816
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 1 mode transport
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0
src ::/0 dst ::/0
socket in priority 0
src ::/0 dst ::/0
socket out priority 0
src ::/0 dst ::/0
socket in priority 0
src ::/0 dst ::/0
socket out priority 0
waits for your valued feedback.
Offline
Configuration file not working,
conn l2tp
authby=secret
keyexchange=ikev1
keyingtries=1
auto=add
dpdaction=clear
dpddelay=300s
type=transport
ike=3des-sha1-modp1024
left=%defaultroute
leftsubnet=172.18.0.0/16
leftprotoport=17/1701
right=dialingipforvpnserver
rightsubnet=vpnserversubnet
rightid=%any
rightprotoport=17/1701
leftnexthop=%defaultroute
rightnexthop=%defaultroute
Offline
Any particular reason running this connection in 'transport' mode?
I was under the impression that you would use transport mode only
for host to host communication protection. Try switching it back to
'tunnel' mode if your particular setup does not restrict this option
and see if it works.
I've tested a quick setup in virtualbox/centos/strongswan and it
seems to be working.
Offline
Thanks for the reply my dear.
Kindly share your ipsec.conf if possible, also kindly inform strong swan version.
Offline
Hi. I have used your config for the testing purposes, except that I've changed the type=tunnel from type=transport,
and populated 'dialingipforvpnserver' and 'vpnserversubnet' variables with relevant to my lab topology values.
I used strongswan simply because CentOS7 (my testing VM) has it as a package, and it saved me the time to
build openswan from source or search it through 3rd party repos. Also strongswan has good documentation,
and I have used it in the past. Though I believe the changes in the configuration mention above should work
with openswan as well.
Last edited by jnbrains (2016-08-27 15:01:40)
Offline
Thanks for the reply.
Please inform, what is the result you have achieved from given configuration file, weather you are successfully connected and routes added automatically or you are unable to connect with it or routes not added automatically.we have tested it with both strong swan and open swan, we can connect to vpn server successfully, but we need to add routes manually.
Please share your result here,for both configuration, your one and given above, routes adding automatically for you?
Kindly share your ipsec.conf, according to your lab.
Last edited by ideagenius (2016-08-28 04:49:32)
Offline
I'll try to share the lab setup later today when I'm back in from a computer.
btw you should not expect to see the routes added to the main routing table.
Usually they're added 'automagically' to a separate routing table, which is
'looked up' before the main routing table (see priority number).
After the tunnel is up you can verify if a route is added with:
# ip route get <IP_ADDRESS_FROM_REMOTE_SUBNET>
You can see the 'ipsec' routing table by reviewing the routing policy database:
# ip rule list
There will the usual local,main,default tables, and there should be at least
one more (depending on your setup) - usually it does not have a name
just a numberic value and priority lower than the main routing table.
And you can view that specific table entries with:
# ip route list table <NAME|NUMBER>
Offline
Thanks for your reply.
Route corresponding to vpn server gateway also added for me in routing table after successful connection, but it did not changes default route which is 0.0.0.0, what i have to do is to delete default route, add default route pointing to pp0 interface, when i disconnects vpn, i need to manually remove this route and have to add back the default route pointing to local isp.
what i need is to avoid this manual overhead.
Waiting on you for your configuration file, also your as usual valued feedback.
Offline
I'm starting to believe I've misunderstood your setup. I have
assumed you're trying to set up site-to-site ipsec vpn connection.
Are you referring to vpn client using openswan and xl2tpd?
My guess based on the above mentioned ppp0 interface and
the desire to route all traffic through the vpn connection.
Offline
Thanks for your reply, Apologize from my side as well, if i am unable to clear you my problem.
I am using paid vpn service, in order to securely tunnel my internet traffic world wide, previously i am using PPTP, but recently i get to know, it has been cracked, so i have started using L2TP, but the curse i am having with it, its manual routing entry. Yes i want to route all my traffic to vpn server, i am using openswan and xl2tp. what i want to figure out is any configuration parameter to avoid manual routing entry. as mentioned above.
Waits for your valued feedback.
Offline
In that case I guess the easiest fix would end up with 'up' and 'down' ppp script in
/etc/ppp - there should be couple of folders like ip-up.d and ip-down.d where you can
put shell scripts to be executed on ppp interface 'up' and interface 'down' events.
You can easily write up two small scripts to add and remove default route via the
ppp0 interface (grab the remote ip address from the ppp0 interface and route towards
it). One more tip - you can set you network setting for the default route with higher
metric (100 for example) and the with you ppp scripts you would only add or remove
default route with default metric, without touching the system default which will be
ignored due to worse metric.
Offline