Routing problems

mp@etlsolutions.com

Hello all, I've got a problem where remote TUN VPN users can not ping/connect to servers on another VPN off of the main server they connect to.
Their connection to the main server at our office works perfectly and is quick to connect.
The site-to-site VPN from our office to an offsite LAN also works perfectly.

Office is: 192.168.250.0/24, remote LAN is 192.168.248.0/24 and both LANs can see each other.
Remote users on TUN VPN get 192.168.100.xx/24, iptables rule on VPN server SNATs (or MASQUERADEs, I've tried both) their VPN connection to the IP of the VPN server and they can see all of the 192.168.250.0/24 LAN.

But, if they try to get further to the 192.168.248.0/24 LAN it just times out. I've tried all manner of route/iroute, static routes, firewall rules and I'm now stuck so would like some help please if someone would be so kind.

Thanking you kindly in advance.
Martin

UserVPN.conf

verb 3
dev tun5
comp-lzo
lport 5000
rport 5000
auth SHA256
mode server
user nobody
persist-key
persist-tun
reneg-sec 60
group nogroup
ping-timer-rem
max-clients 10
topology subnet
keepalive 10 60
proto tcp-server
persist-local-ip
persist-remote-ip
server 192.168.100.0 255.255.255.0
status /var/log/openvpn/status.log
log-append /var/log/openvpn/openvpn.log
client-config-dir /etc/openvpn/userkeys/

route 192.168.248.0 255.255.255.0 192.168.250.1

tls-server
tls-auth ta.key 0
cipher AES-256-CBC
ca /etc/openvpn/keys/ca.crt
dh /etc/openvpn/keys/dh2048.key
tls-auth /etc/openvpn/keys/ta.key
key /etc/openvpn/keys/OpenVPN.key
cert /etc/openvpn/keys/OpenVPN.crt

push "dhcp-option DNS 192.168.250.1"
push "dhcp-option DNS 192.168.250.2"
push "route 192.168.248.0 255.255.255.0"
push "route 192.168.250.0 255.255.255.0"

Client.conf

pull
verb 3
nobind
dev tun
comp-lzo
port 5000
tls-client
auth SHA256
persist-key
persist-tun
topology subnet
proto tcp-client
cipher AES-256-CBC
remote vpn.server.com

ca ca.crt
tls-auth ta.key 1
key user.key
cert user.crt

mp@etlsolutions.com

And here's the routing table on the openvpn server:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.23.3.1       0.0.0.0         UG    0      0        0 eth1
10.23.3.0       0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.100.0   0.0.0.0         255.255.255.0   U     0      0        0 tun5
192.168.248.0   192.168.248.1   255.255.255.0   UG    0      0        0 tun0
192.168.248.1   0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.250.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0

Because of the infrastructure at the building we're in our DMZ interface is unfortunately also NAT'd from its real IP, hence the 10.23.3.1 above.

mp@etlsolutions.com

No ideas anyone?

TiTex

I think if somebody would give you some feedback , more info is needed
like firewall ( iptables ) rules on both sides of the LAN's openvpn
routing table from both servers
if the default gateway for your LAN clients is the vpn server or another device/router
and also if you have client configurations in /etc/openvpn/userkeys/

mp@etlsolutions.com

Good point TiTex, yes the default gateway is also the VPN server, the only file in /etc/openvpn/userkeys/ is one for my test account and that just contains: ifconfig-push 192.168.100.163 255.255.255.0 (I've also tried without the client-config-dir option but same result).
I've been using openvpn for years and always wanted to change the client vpns from tap to tun, this one issue is all that's now holding me back.

Server IP tables are:

$IPT -A INPUT   -m state --state ESTABLISHED,RELATED                  -j ACCEPT
$IPT -A INPUT   -m state --state NEW -p udp  --dport     5000 -s 0/0  -j ACCEPT # client vpns
$IPT -A INPUT   -m state --state NEW -p udp  --dport     3138 -s 0/0  -j ACCEPT # site 2 site vpn

$IPT -A OUTPUT  -m state --state ESTABLISHED,RELATED                  -j ACCEPT
$IPT -A OUTPUT  -m state --state NEW -p all                   -o $WAN -j ACCEPT # output to WAN

$IPT -A FORWARD -m state --state ESTABLISHED,RELATED                  -j ACCEPT
$IPT -t nat -A POSTROUTING -s 192.168.250.0/24                        -o $WAN -j MASQUERADE
$IPT -A FORWARD -m state --state NEW -i $LAN                  -o $WAN -j ACCEPT # LAN to WAN
$IPT -A FORWARD -m state --state NEW -i $WAN                  -o $LAN -j ACCEPT # WAN to LAN

$IPT -A INPUT   -m state --state NEW -p all                   -i tun+ -j ACCEPT
$IPT -A OUTPUT  -m state --state NEW -p all                   -o tun+ -j ACCEPT
$IPT -A FORWARD -m state --state NEW -i $LAN                  -o tun+ -j ACCEPT # LAN to tunnels
$IPT -A FORWARD -m state --state NEW -i tun+                  -o $LAN -j ACCEPT # tunnels to LAN
$IPT -t nat -A POSTROUTING -s 192.168.100.0/24                        -j SNAT --to-source 192.168.250.1

Hopefully that mite shed some more light on the problem.
Thank you.

mp@etlsolutions.com

$IPT -A INPUT   -m state --state ESTABLISHED,RELATED                  -j ACCEPT
$IPT -A INPUT   -m state --state NEW -p udp  --dport     5000 -s 0/0  -j ACCEPT # client vpns
$IPT -A INPUT   -m state --state NEW -p udp  --dport     3148 -s 0/0  -j ACCEPT # site 2 site vpn

$IPT -A OUTPUT  -m state --state ESTABLISHED,RELATED                  -j ACCEPT
$IPT -A OUTPUT  -m state --state NEW -p all                   -o $WAN -j ACCEPT # output to WAN

$IPT -A FORWARD -m state --state ESTABLISHED,RELATED                  -j ACCEPT
$IPT -t nat -A POSTROUTING -s 192.168.250.0/24                        -o $WAN -j MASQUERADE
$IPT -A FORWARD -m state --state NEW -i $LAN                  -o $WAN -j ACCEPT # LAN to WAN
$IPT -A FORWARD -m state --state NEW -i $WAN                  -o $LAN -j ACCEPT # WAN to LAN

$IPT -A INPUT   -m state --state NEW -p all                   -i tun+ -j ACCEPT
$IPT -A OUTPUT  -m state --state NEW -p all                   -o tun+ -j ACCEPT
$IPT -A FORWARD -m state --state NEW -i $LAN                  -o tun+ -j ACCEPT # LAN to tunnels
$IPT -A FORWARD -m state --state NEW -i tun+                  -o $LAN -j ACCEPT # tunnels to LAN
$IPT -t nat -A POSTROUTING -s 192.168.100.0/24                        -j SNAT --to-source 192.168.250.1

IP tables on remote server:

$IPT -A INPUT   -m state --state ESTABLISHED,RELATED                   -j ACCEPT
$IPT -A INPUT   -m state --state NEW -p udp  --dport      3148 -s 0/0  -j ACCEPT # site 2 site vpn

$IPT -A OUTPUT  -m state --state ESTABLISHED,RELATED                  -j ACCEPT
$IPT -A OUTPUT  -m state --state NEW -p all                   -o $WAN -j ACCEPT # output to WAN

$IPT -A FORWARD -m state --state ESTABLISHED,RELATED                  -j ACCEPT
$IPT -t nat -A POSTROUTING -s 192.168.248.0/24                        -o $WAN -j MASQUERADE
$IPT -A FORWARD -m state --state NEW -i $LAN                  -o $WAN -j ACCEPT # LAN to WAN
$IPT -A FORWARD -m state --state NEW -i $WAN                  -o $LAN -j ACCEPT # WAN to LAN

$IPT -A INPUT   -m state --state NEW -p all                   -i tun+ -j ACCEPT
$IPT -A OUTPUT  -m state --state NEW -p all                   -o tun+ -j ACCEPT
$IPT -A FORWARD -m state --state NEW -i $LAN                  -o tun+ -j ACCEPT # LAN to tunnels
$IPT -A FORWARD -m state --state NEW -i tun+                  -o $LAN -j ACCEPT # tunnels to LAN

Routing table on remote server:

0.0.0.0         92.xx.xx.xx     0.0.0.0         UG    0      0        0 eth0
92.xx.xx.xx     0.0.0.0         255.255.255.248 U     0      0        0 eth0
192.168.248.0   0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.250.0   192.168.250.1   255.255.255.0   UG    0      0        0 tun0
192.168.250.1   0.0.0.0         255.255.255.255 UH    0      0        0 tun0

Hopefully that mite shed some more light on the problem.
Thank you.

TiTex

So you have two openvpn server configurations on your Office server ?
-one connecting the remote LAN to your office and one for vpn clients

And the client config you posted is for a vpn client , not the remote vpn server's config
correct?

mp@etlsolutions.com

Yes, 100% correct, that's what I've configured.
Office lan, 192.168.250.0/24.
Remote lan, 192.168.248.0/24.
Remote users, 192.168.100.0/24.

Main office and remote lan completely see each other, remote users can see all of office lan.
Remote users are SNAT'd from 192.168.100.xx to 192.168.250.1 (office lan gw and openvpn server).
Remote users can not get to remote lan though.

It's probably something stupid I've overlooked but i just can't see it and have been too close to this for too long.

Thanks TiTex.

TiTex

Okay , so this i how i would do it
on Main Office server - two vpn server configs
1. p2p tunnel between main office server and remote vpn server
in each servers configuration you should have a "route" statement like
Main Office config:

route route 192.168.248.0 255.255.255.0

Remote Office config:

route route 192.168.250.0 255.255.255.0

after this is done , and vpn tunnel is up on both sides , the two LAN's should see each other with the condition that ip_forward is enabled on the servers and for the LAN on both sides the openvpn server is also the default gateway.

2. On Main Office , create a second vpn server like the one you posted in the first message ( UserVPN.conf ) , from which you can remove the "route" statement because it's not needed.
Add am iptables rule like

iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o tun0 -j MASQUERADE

where tun0 , is the interface for the first tunnel between your two offices

at this point your remote clients , connecting to the second tunnel on your main office server , should also have connectivity to the remote lan.

i've done this in a test environment and it works as expected.

--------------------------------------------------------
3. This said you can also set it up using a single VPN Server , running on in the main office and the remote office server + remote clients as vpn clients.
more about it here https://community.openvpn.net/openvpn/wiki/RoutedLans

which basically boils down to , having the main office server set up with a config like this proto udp
port 1194
dev tun

topology subnet
server 192.168.100.0 255.255.255.0

persist-key
persist-tun
keepalive 10 6

remote-cert-tls client
client-to-client

tls-auth ta.key 0
ca /etc/openvpn/keys/ca.crt
dh /etc/openvpn/keys/dh2048.key
tls-auth /etc/openvpn/keys/ta.key
key /etc/openvpn/keys/OpenVPN.key
cert /etc/openvpn/keys/OpenVPN.crt

client-config-dir /etc/openvpn/userkeys/

route 192.168.248.0 255.255.255.0

push "dhcp-option DNS 192.168.250.1"
push "dhcp-option DNS 192.168.250.2"
push "route 192.168.248.0 255.255.255.0"
push "route 192.168.250.0 255.255.255.0"

verb 3
status /var/log/openvpn/status.log
log-append /var/log/openvpn/openvpn.log in /etc/openvpn/userkeys/ , having a file named remote if common name of your remote server certificate is remote , with an

iroute 192.168.248.0 255.255.255.0

which tells openvpn server to route this specific network to the remote office server (vpn client) , and also tells the remote office server (vpn client) to not route the 192.168.248.0 255.255.255.0 network over the vpn (since this is the local lan)
you do not need to add any other iptables nat rule , but you need ip_forward enabled on both servers.

Pick the method that it's easier to understand or set up for you

mp@etlsolutions.com

That's absolutely fantastic help TiTex, thank you so much.
I've opted for the first approach for now as there isn't a lot to change aside from removing the route 192.168.248.0 255.255.255.0 line and modifying the SNAT rule to your MASQUERADE one.
Both changes have been made but I can't restart the tunnels or the iptables until no one is using them so will test it tonight from home.

I'll let you know how I get on Sir.
Thank you again.
Martin

mp@etlsolutions.com

Hi Titex, can I just ask about your second option?, which to me seems the better solution.
I will also need to add another remote site and if I go with option 2 (the routed lans) I understand that I'm sort of moving away from site-to-site/p-to-p tunnels and having a more client-server type of set up.
And if that's the case then is there a way to not see/allow traffic from anything else behind each of the remote users' lans please?
One of the reasons for moving from tap (bridged) remote clients was to stop all the rubbish traffic from their side spilling over into our main lan.

Didn't get a chance last night to test the new config so I'll do it later.
Thanks again.
Martin

TiTex

I'm not sure what you mean by

And if that's the case then is there a way to not see/allow traffic from anything else behind each of the remote users' lans please?

which user ? 🙂

Just to clarify , in the second example traffic between clients is not NAT'ed , so i guess you can block the traffic with iptables on either side of the tunnel if you know their IP address , but i'm not sure about this mainly because client-to-client my interfere. Try it out and let us know

mp@etlsolutions.com

Sorry, what I mean is that if say a remote staff member connects via VPN to the main office vpn server from home, we don't want to be able to connect or see any other devices on their home network, and we don't want those devices to see anything on the work network either.
Your second solution is what I want to aim for but I'll have to try and get the first solution working first as that's far less to have to change.
With the second solution do you mean that I don't need any NAT rules at all in iptables as the routing will be internal to openvpn?

Yes, I'll do a full write up once I've got the complete set up working.
Martin

mp@etlsolutions.com

Ok, tried ur 1st solution and I can't get it to work. Main office 9192.168.250.0/24) sees remote lan (192.168.248.0/24) and vice versa, remote client (192.168.100.0/24) sees main office but not remote lan.
This is where I was at before and changing the firewall rule to masquerade as tun0 hasn't helped. :-(
When I'm on the vpn server of the remote lan it can't see the 192.168.100.1 interface on the main office server which I think is where the problem is??
But shouldn't the masquerade rule make the remote client traffic (192.168.100.0/24) look like it's coming from the office lan (192.168.250.0/24)?

This one has me stumped.

mp@etlsolutions.com

I've fixed it!!!!!!
All that was missing wa a rule to forward the remote client tunnel to the remote lan tunnel and another the other way, and it works!!!! Yay.
Can't believe I overlooked that, what a muppet!!!

Thank you so much Titex for your help, going back over your post helped me re-think the set up logically and your masquerade rule fixed the NAT'ing.
You are a credit to the open source community Sir.

Many thanks again.
(One very relieved) Martin
:-)

TiTex

Thank you and glad it worked out.
For what you want , take a look at these options in the manual
redirect-gateway - especially the block-local flag
push option
client-connect - instead of using client-to-client you could set up iptables (netfilter) rules on your own to achieve the same thing, but i don't think you need that
route-nopull - it's an option that a client can add in their config , which might interfere with redirect-gateway , haven't tested or used this option , so you have to see.

For other access limitations you can use iptables FORWARD chain
i.e on main office VPN server

iptables -A FORWARD -s 192.168.100.101 -d 192.168.250.10 -j DROP

- will block vpn client with ip 192.168.100.101 to connect to 192.168.250.10
be aware that you need to add a rule like above on the remote lan (192.168.248.0/24) vpn client (server) , to block a vpn client to connect to a device in that network if client-to-client is enabled.

Have fun experimenting 🙂