allow ssh via on non vpn address while vpn is open

[skrewt]

Thanks for the untold amounts of help I received in the IRC channel, as well as the help from this forum, I have finally gotten this to work. Per the link posted above to a similar thread, the following 2 lines were all that was needed to complete this setup:

Code: Select all

ip rule add from <internal IP of SSH server/VPN client> table 10
ip route add default via <internal IP of gateway/router> table 10

Everything works as it should. Again, thank you so much! I will continue to hang out in the IRC channel and provide others with help if I am able to.

[mops]

Hello.
I have recently faced this very issue and in extensive research found bits and pieces of information around this subject but not the total and complete solution.
Therefore I'd like to share the solution to the problem.
Note this guide is based around linux, I'm not sure how to do the same in windows, but I imagine it is possible, perhaps some 3rd party software allows to configure it.

The issue:
Routing is traditionally done on level 3 of OSi reference model. This implies that "traditional" routing is based around hosts or networks. So i.e. it is possible to say, all traffick from/to this host/network go via this gateway/interface.

The challenge:
We want to route traffick based on source or destination port, which is something that "traditional" Level 3 routing does not support.

I my particular case, I'm using commercial "anonymising" VPN service. OpenVPN config is provided by the service, and once openvpn client is started then all the traffick is redirected via vpn. However then http server no longer works (which is using the public, nonvpn ip). This machine is also serving as Wireless access point, so it routes packets between wlan and internet.

The solution:
Linux iproute2 has the capability of routing packets based on iptables rules, so anything you can specify as an iptable rule can be routed differently.

Very important:
ipforwarding has to be enabled and rp_filter has to be disabled for involved interfaces.
Especially the later is hardly mentioned in any documentation, and these days it is enabled in most distros. Having this enabled will most ikely screw up your attempts to mark and route the packets. the rp_filter, aka Reverse Path Filter, it inspects incomming packet and checks whether the the packet has valid return path (via gateway). If not it will drop the packet. I was tearing my hair out, seeing incomming http requests to the server in the tcpdump, however apache would not log any access attempts. This is because rp_filter was dropping them. It would not show in iptables counters.

Anyways, without further ado:

to check for ip_forwarding and rp_filter:

Code: Select all

sysctl net.ipv4.conf.all.rp_filter = 1
sysctl -a | grep \\.rp_filter
sysctl net.ipv4.conf.[interface].rp_filter = 0

Then create a new routing table:

Code: Select all

echo 100 openvpn >> /etc/iproute2/rt_tables
ip route add default via <nonvpn gateway ip> dev <nonvpn interface> table nonvpn
ip route show table nonvpn

Add ip forwarding rule

Code: Select all

ip rule mark fwmark 1 lookup nonvpn
ip rule show

Create iptables rules to mark packets intended to route via nonvpn table. Those rules need to go to the 'mangle' iptable. Rules which mark packets originating from the localhost have to go into the 'OUTPUT' chain, whereas rules marking packets from different networks go to 'PREROUTING' chain

Code: Select all

iptables -A OUTPUT -t mangle -p tcp --sport 80 -j MARK --set-mark=1 //reply packets from http server
iptables -A OUTPUT -t mangle -p tcp --sport 22 -j MARK --set-mark=1 //reply packets from ssh
iptables -A PREROUTING -t mangle -i wlan0 -j MARK --set-mark=1 //packets from wlan on dev box

That's all.

Troubleshooting tools i found usefull:
1. Use tcpdump or wireshark to see the packets sent/recieved on the relevant interface(s)
2. reset iptables counters (-Z) and then generate packets and see the counters as to which tables/chains/rules packets get to and which not.

Credits:
http://www.tldp.org/HOWTO/Adv-Routing-H ... ilter.html
http://lartc.org/howto/lartc.cookbook.f ... intro.html
http://www.wlug.org.nz/SourceBasedRouting
http://www.tolaris.com/2009/07/13/disab ... -networks/

[chapata]

I was always wondering how to do this. It was such a stressful task! Thank you soooo much! Good luck to you all!

[chapata]

Looking for topic7175.html link, is that working for anyone?


Arthur Chapata | The flirt guy

[aftab]

Awesome post learned a lot from here thanks for this community.

[ecoutin]

Hello.
I have recently faced this very issue and in extensive research found bits and pieces of information around this subject but not the total and complete solution.
Therefore I'd like to share the solution to the problem.
Note this guide is based around linux, I'm not sure how to do the same in windows, but I imagine it is possible, perhaps some 3rd party software allows to configure it.

The issue:
Routing is traditionally done on level 3 of OSi reference model. This implies that "traditional" routing is based around hosts or networks. So i.e. it is possible to say, all traffick from/to this host/network go via this gateway/interface.

The challenge:
We want to route traffick based on source or destination port, which is something that "traditional" Level 3 routing does not support.

I my particular case, I'm using commercial "anonymising" VPN service. OpenVPN config is provided by the service, and once openvpn client is started then all the traffick is redirected via vpn. However then http server no longer works (which is using the public, nonvpn ip). This machine is also serving as Wireless access point, so it routes packets between wlan and internet.

The solution:
Linux iproute2 has the capability of routing packets based on iptables rules, so anything you can specify as an iptable rule can be routed differently.

Very important:
ipforwarding has to be enabled and rp_filter has to be disabled for involved interfaces.
Especially the later is hardly mentioned in any documentation, and these days it is enabled in most distros. Having this enabled will most ikely screw up your attempts to mark and route the packets. the rp_filter, aka Reverse Path Filter, it inspects incomming packet and checks whether the the packet has valid return path (via gateway). If not it will drop the packet. I was tearing my hair out, seeing incomming http requests to the server in the tcpdump, however apache would not log any access attempts. This is because rp_filter was dropping them. It would not show in iptables counters.

Anyways, without further ado:

to check for ip_forwarding and rp_filter:

Code: Select all

sysctl net.ipv4.conf.all.rp_filter = 1
sysctl -a | grep \\.rp_filter
sysctl net.ipv4.conf.[interface].rp_filter = 0

Then create a new routing table:

Code: Select all

echo 100 openvpn >> /etc/iproute2/rt_tables
ip route add default via <nonvpn gateway ip> dev <nonvpn interface> table nonvpn
ip route show table nonvpn

Add ip forwarding rule

Code: Select all

ip rule mark fwmark 1 lookup nonvpn
ip rule show

Create iptables rules to mark packets intended to route via nonvpn table. Those rules need to go to the 'mangle' iptable. Rules which mark packets originating from the localhost have to go into the 'OUTPUT' chain, whereas rules marking packets from different networks go to 'PREROUTING' chain

Code: Select all

iptables -A OUTPUT -t mangle -p tcp --sport 80 -j MARK --set-mark=1 //reply packets from http server
iptables -A OUTPUT -t mangle -p tcp --sport 22 -j MARK --set-mark=1 //reply packets from ssh
iptables -A PREROUTING -t mangle -i wlan0 -j MARK --set-mark=1 //packets from wlan on dev box

That's all.

Troubleshooting tools i found usefull:
1. Use tcpdump or wireshark to see the packets sent/recieved on the relevant interface(s)
2. reset iptables counters (-Z) and then generate packets and see the counters as to which tables/chains/rules packets get to and which not.

Credits:
http://www.tldp.org/HOWTO/Adv-Routing-H ... ilter.html
http://lartc.org/howto/lartc.cookbook.f ... intro.html
http://www.wlug.org.nz/SourceBasedRouting
http://www.tolaris.com/2009/07/13/disab ... -networks/

I know this is a very old thread but thought I would share my knowledge on the matter so anyone that come to this post with similar problem can use it.

If I understand right what you are trying to do is send all packets to that destination over the VPN but not if the destination port is 22 (SSH), at least this is what I do with my home network, so I can access my servers via SSH if there's a problem with the tunnel.

I simply add a NAT rule with a negate option for SSH, this solution uses DNAT, not sure if this is acceptable on your configuration.

Code: Select all

iptables -A PREROUTING -t nat -d <server_public_IP> -p tcp -m tcp ! --dport 22 -j DNAT --to-destination <server_VPN_IP>

So we are telling iptables to NAT anything going to my server public IP except on port 22 to the servers VPN IP, the normal routes will take care of sending those packets over the VPN tunnel

Hope this helps anyone in the future.

Kadu

I tried both these approaches and here's what I got:

1.-I connect through SSH to the client machine and then fire openvpn to connect to the Access Server(the OpenVPN server)
2.-As soon as openvpn succeeds I lose the SSH connection (I know it's succeeding because I write status and log files to the client machine and I review them after I reboot it: It's an Amazon cloud test machine)
3.- Once my client machine connects to VPN I cannot SSH back into it.

What am I missing here?

I asked around and some told me I needed to create a split tunnel and I thought that maybe doing ssh -w could help with that.

it looks like I'm confusing myself, so I'll go over the quotes and post what are my sticking points.

[ecoutin]

the requests to sshd come over ethernet interface, and leave over the tunnel.
you would need to set a more specific route to the IP/subnet that you want to reach your sshd, but no traffic to that IP/subnet will go over the vpn...
viewtopic.php?f=15&t=7161

I figured out.

THIS is how you do it and it works perfectly for the scenario I have:

topic7161.html#p7975

Thanks krzee, much easier solution.

[Blondiez78]

the requests to sshd come over ethernet interface, and leave over the tunnel.
you would need to set a more specific route to the IP/subnet that you want to reach your sshd, but no traffic to that IP/subnet will go over the vpn...
viewtopic.php?f=15&t=7161

It's frustrating when routing limitations impact VPN effectiveness. Unfortunately, routes are address-centric, not port-specific.

[MatiGU]

Hi guys, I'm new to the forum, but I can't open threads... what can I do or who can I contact to resolve it?