Exclude one Port from VPN connection - Networking - NetworkManager - Debian Linux - Routing - OpenVPN

  • Questioner

    I have a Raspberry Pi ( - pi local IP address, static) running Raspbian (debian linux) behind my Verizon ActionTec Router ( - gateway).

    It is running a VNC server (tightvncserver).

    The Pi can be accessed by ssh to the Public IP of the router which forwards port 22 to the Pi.

    To access the VNC server I use

    ssh [email protected] -L 5901:localhost:5901

    where X.X.X.X is the Public IP address of the Verizon ActionTec Router

    This takes the 5901 of my connecting device (my laptop) and I believe forwards it to the Raspberry Pi.

    I can then use the command:


    to connect via the VNC Viewer program on my laptop to view the Raspberry Pi via VNC.

    I am using the NetworkManger program on the Raspberry Pi to connect to my home network.

    Here comes the tricky part:

    I want to use the Raspberry Pi on a VPN. I have verified and connected it successfully to the VPN using NetworkManager. The VPN uses the OpenVPN VPN protocol. The Raspberry now acquires an IP address of Y.Y.Y.Y

    Obviously, when I connect the Raspberry to the VPN I can no longer access it remotely because all of its ports are forwarded through the VPN.

    1. The question is, how do I exclude ports from the VPN client (preferably) or network? so that I would still be able to remotely access it? Specifically, I want to access port 22 (ssh), 5901 (VNC), 21(ftp), and maybe even 80(http).

    I know the point of a VPN client is to take all of your connections and tunnel them through to the destination VPN server so everything is encrypted by the destination, but for remote purposes like VNC I want to exclude some of those ports.

    I found this method on another site that was being used with a tomato firmware router letting every port other than 119 go through the VPN tunnel:

    ip route add default table 100 via [Your ISP's Gateway]
    ip rule add fwmark 1 table 100
    ip route flush cache
    iptables -t mangle -I PREROUTING -p tcp --dport 119 -j MARK --set-mark 1
    1. Could this iptables method be applied directly to the Raspberry Pi or is it just a method for a router?

    I would think that there must be a way to exclude one port from being forwarded through the VPN on the Debian OS level.

    The VPN creates a tun0 interface. The

    Doing other further research I found commands which can be used to ONLY send port 80 and 443 through the VPN (opposite of what I want):

    -A INPUT -i eth0 -p tcp -m tcp --dport 80 -j DROP
    -A INPUT -i eth0 -p tcp -m tcp --dport 443 -j DROP
    -A INPUT -i tun0 -p tcp -m tcp --dport 80 -j ACCEPT
    -A INPUT -i tun0 -p tcp -m tcp --dport 443 -j ACCEPT

    Also, there is a "routes" checkbox in the NetworkManager gui when editing the VPN connection. If you open it, it is titled "Editing IPv4 routes for VPN. You can add, it has columns for: Address, Netmask, Gateway, Metric.

    Underneath the the add section there are two checkboxes:

    _Ignore Automatically obtained routes
    _Use this connection only for resources on its network

    Not sure what I can use the "routes" configuration/options for.

    Any help would be appreciated.

  • Answers
    Know someone who can answer? Share a link to this question via email, Google+, Twitter, or Facebook.

    Related Question

    networking - How do I set up routing for a VPN gateway separate from my main gateway?
  • Questioner

    I have a run of the mill router/firewall set up for my small company's Internet access. I've also added a separate VPN (IPSec) gateway using a Netgear VPN router. The main gateway and VPN gateway have separate public IP addresses, and the VPN clients have a different subnet from the home office LAN (which is just how the Netgear works - I can't put them on the same subnet as everyone else).

    The problem is that traffic between LAN PCs and VPN clients doesn't route correctly. LAN clients can ping VPN clients, but VPN clients cannot ping LAN clients (using Wireshark I see the ping gets to the client, but the client cannot respond).

    I have a routing entry on the main gateway to point all traffic to the VPN subnet to the VPN gateway. However, that doesn't seem to do the trick. The only solution I've found is to add a static routing entry on the all the PCs on the LAN to point them to the VPN gateway for its subnet. However, this doesn't work for embedded devices that don't allow you to do static routing.

    What am I doing wrong?

    Here are the IPs/subnets in question (the public addresses are faked for the sake of privacy):

    LAN: VPN clients:

    LAN Gateway: (WAN: VPN Gateway: (WAN:

    The LAN Gatway has a route for ->

    I have partial success with each PC having a static route for ->


    The VPN gateway is a Netgear ProSafe VPN Firewall FVS338, and the main gateway is an Actiontec MI424-WR (for Verizon FiOS).

  • Related Answers
  • pjz

    Just like you have a route to the main gateway pointing all the traffic to the vpn subnet to the vpn gateway, you need a route in the vpn gateway pointing all traffic to the main subnet to the main gateway.

  • Mike Taber

    This is a rough problem that I've had myself, so here's some info to get you started.

    Actiontec MI424-WR User Guide www.fiberfaq.com/admin/attachments/actiontec_mi424wr_manual.pdf

    Here's a URL to someone's blog who claimed to get it working, but the screenshots are missing so it's a little difficult to follow.


    I would post that as an actual link, but ServerFault doesn't like me as a new user so will only let me post a single link right now.

    Basically, his claim is that the Firewall Filtering rules are blocking some of that return traffic and what you describe is exactly what I saw. Traffic would come out of a private network, hit the desired server(s) and they would respond in kind by replying through the gateway which was the Actiontec router. Then nothing came back through the gateway.

    I played with the Firewall Filtering rules quite a bit but got frustrated because the documentation in the User Guide isn't entirely clear on what is what, nor does it explain what the Filtering Rules contain by default. Even at the most open setting, they seemed to be in place and preventing some traffic. If you make a mistake, it's possible to completely lock yourself out of the router (because it's filtering your traffic) and then you have to do a factory reset to get it working again.

    In the end, the solution that I found to work was to set the Actiontec router into Bridge Mode. To do this, log into the Actiontec router and go to "My Network" and select "Network Connections" on the left. Then click on the "Advanced" button at the bottom of the screen to see all of the network interfaces on your Actiontec.

    You will need to release the IP address from your Actiontec router so that it can be picked up by your own router. Otherwise it won't work. To do this, click on the appropriate "Broadband Connection" link, depending on whether you're set up using Coax or Ethernet. (On my router, both are connected, but only Ethernet is in use. I understand that for the most part, FIOS uses Coax instead).

    Click on Settings at the bottom of the screen, and then you should find an option to Release the IP Address. Do this, and then change the Internet Protocol to "No IP Address". Click Apply and accept the changes, as needed.

    Now that the IP address has been released, you need to change the router into a Bridge. Under the connections, select "Network (Home/Office)" and then click on "Settings". You'll see the word "Bridge" near the top of the screen and several network interfaces under it. To the left of the network interfaces there are some checkboxes. Check the one next to the appropriate Broadband Connection you're using (Coax or ethernet) and also check the box in the STP column. Click Apply and accept as needed to get back to the main section.

    If you haven't done so already, disable the wireless access point. Also, go into the Firewall settings and disable it as much as possible with minimal security. The reason is that the real router you're going to use should be the one taking care of everything, not the Actiontec.

    That's about it. It really sucks to have to use this as a bridge, but it did work. You might find another way to bypass it entirely, but I've been having this problem for quite some time now and this was the first way that I found to get the traffic to route properly. The firewall filtering rules would probably work, but they're a real pain and the documentation isn't much help.