hi everybody
I'm having a, I'd like to think a "regular" VPN with IPsec/xl2tpd and it all works OK, except.. One thing that I never needed but now I do and I wonder.... is it my iptables, or/and routing or maybe VPN server config..?
vpn clients with established tunnels can get to VPN server's NICs/IPs but cannot get through to the net behind the server. Well... they can, but only if on a host (eg. 192.168.2.33) on VPN server's net I do:
route add -host 192.168.2.10 gw 192.168.2.100 # 192.168.2.10 is VPN client
I thought this I'd not need since that local net (eg. 192.168.2.33) use VPN server's 192.168.2.100 as the default gw.
is it by design and nature of that VPN solution it works this way or I actually have missed/messed up something? I hope the latter and adding routing on per "to host" basis is redundant.
many thanks
On 1/26/2016 5:37 AM, lejeczek wrote:
I'm having a, I'd like to think a "regular" VPN with IPsec/xl2tpd and it all works OK, except.. One thing that I never needed but now I do and I wonder.... is it my iptables, or/and routing or maybe VPN server config..?
vpn clients with established tunnels can get to VPN server's NICs/IPs but cannot get through to the net behind the server. Well... they can, but only if on a host (eg. 192.168.2.33) on VPN server's net I do:
route add -host 192.168.2.10 gw 192.168.2.100 # 192.168.2.10 is VPN client
I thought this I'd not need since that local net (eg. 192.168.2.33) use VPN server's 192.168.2.100 as the default gw.
is it by design and nature of that VPN solution it works this way or I actually have missed/messed up something? I hope the latter and adding routing on per "to host" basis is redundant.
your VPN client shouldn't be on the same subnet as your LAN. your LAN hosts expect 192.168.2.10 to be a local address and not to have to use the gateway. you probably could make this work with some sort of proxy arp but ugh, bridged VPNs are problematic.
On 26/01/16 16:26, John R Pierce wrote:
On 1/26/2016 5:37 AM, lejeczek wrote:
I'm having a, I'd like to think a "regular" VPN with IPsec/xl2tpd and it all works OK, except.. One thing that I never needed but now I do and I wonder.... is it my iptables, or/and routing or maybe VPN server config..?
vpn clients with established tunnels can get to VPN server's NICs/IPs but cannot get through to the net behind the server. Well... they can, but only if on a host (eg. 192.168.2.33) on VPN server's net I do:
route add -host 192.168.2.10 gw 192.168.2.100 # 192.168.2.10 is VPN client
I thought this I'd not need since that local net (eg. 192.168.2.33) use VPN server's 192.168.2.100 as the default gw.
is it by design and nature of that VPN solution it works this way or I actually have missed/messed up something? I hope the latter and adding routing on per "to host" basis is redundant.
your VPN client shouldn't be on the same subnet as your LAN. your LAN hosts expect 192.168.2.10 to be a local address and not to have to use the gateway. you probably could make this work with some sort of proxy arp but ugh, bridged VPNs are problematic.
after I mailed my message I did play around with it this exact way, it works and is the simplest way, most likely the proper way. thanks
On 26/01/16 16:26, John R Pierce wrote:
On 1/26/2016 5:37 AM, lejeczek wrote:
I'm having a, I'd like to think a "regular" VPN with IPsec/xl2tpd and it all works OK, except.. One thing that I never needed but now I do and I wonder.... is it my iptables, or/and routing or maybe VPN server config..?
vpn clients with established tunnels can get to VPN server's NICs/IPs but cannot get through to the net behind the server. Well... they can, but only if on a host (eg. 192.168.2.33) on VPN server's net I do:
route add -host 192.168.2.10 gw 192.168.2.100 # 192.168.2.10 is VPN client
I thought this I'd not need since that local net (eg. 192.168.2.33) use VPN server's 192.168.2.100 as the default gw.
is it by design and nature of that VPN solution it works this way or I actually have missed/messed up something? I hope the latter and adding routing on per "to host" basis is redundant.
your VPN client shouldn't be on the same subnet as your LAN. your LAN hosts expect 192.168.2.10 to be a local address and not to have to use the gateway. you probably could make this work with some sort of proxy arp but ugh, bridged VPNs are problematic.
heh, I'm thinking about it again, if you use different subnet... there will be a struggle on how to push routing to vpn clients when they don't use vpn connection as default gateway. How to get around it, how to tell clients (ideally in a automated/unattended way) about VPN server other subnets? I think is must be a subnet/range the easiest way out.
On 03/31/2016 07:35 AM, lejeczek wrote:
there will be a struggle on how to push routing to vpn clients when they don't use vpn connection as default gateway. How to get around it, how to tell clients (ideally in a automated/unattended way) about VPN server other subnets?
L2TP VPNs are ppp links. There is not, to the best of my knowledge, a mechanism to push routes to the clients. If you configure a client not to use the ppp link as its default route, you must also provide all of the routes that should be associated with the VPN, even when you are assigning addresses in the same IP subnet as the hosts you want to reach.
On 01/26/2016 05:37 AM, lejeczek wrote:
vpn clients with established tunnels can get to VPN server's NICs/IPs but cannot get through to the net behind the server. Well... they can, but only if on a host (eg. 192.168.2.33) on VPN server's net I do:
route add -host 192.168.2.10 gw 192.168.2.100 # 192.168.2.10 is VPN client
If the VPN isn't hosted on the device with the default gateway, then that route should be added to the gateway device. Proxy arp is an option if you use addresses in the same broadcast domain, but adding a route in the gateway device should work for all configurations.
On 1/26/2016 9:14 AM, Gordon Messmer wrote:
On 01/26/2016 05:37 AM, lejeczek wrote:
vpn clients with established tunnels can get to VPN server's NICs/IPs but cannot get through to the net behind the server. Well... they can, but only if on a host (eg. 192.168.2.33) on VPN server's net I do:
route add -host 192.168.2.10 gw 192.168.2.100 # 192.168.2.10 is VPN client
If the VPN isn't hosted on the device with the default gateway, then that route should be added to the gateway device. Proxy arp is an option if you use addresses in the same broadcast domain, but adding a route in the gateway device should work for all configurations.
not in this case, because a random host like 192.168.2.33 thinks the remote VPN client 192.168.2.10 is on the same LAN, so it wouldn't even forward the packet to the gateway unless the gateway responds to the ARP for 192.168.2.10
On 26/01/16 17:19, John R Pierce wrote:
On 1/26/2016 9:14 AM, Gordon Messmer wrote:
On 01/26/2016 05:37 AM, lejeczek wrote:
vpn clients with established tunnels can get to VPN server's NICs/IPs but cannot get through to the net behind the server. Well... they can, but only if on a host (eg. 192.168.2.33) on VPN server's net I do:
route add -host 192.168.2.10 gw 192.168.2.100 # 192.168.2.10 is VPN client
If the VPN isn't hosted on the device with the default gateway, then that route should be added to the gateway device. Proxy arp is an option if you use addresses in the same broadcast domain, but adding a route in the gateway device should work for all configurations.
not in this case, because a random host like 192.168.2.33 thinks the remote VPN client 192.168.2.10 is on the same LAN, so it wouldn't even forward the packet to the gateway unless the gateway responds to the ARP for 192.168.2.10
yes, I see I might not have said it clear in my last message - like John says - move your VPN local IP to a different subnet and it works, otherwise route on 'per-host basis' to each VPN client - wrong & undesired.
-
Gordon Messmer -
John R Pierce -
lejeczek