OpenVPN, don't route outbound traffic through VPN?

[Akaihiryuu]

I'm using a VPN so I can get a public IP address for my inbound traffic (my internet service does not give me a public IP). The public IP is taken care of. Inbound traffic works fine. The problem is, my OUTBOUND traffic is also being routed through the VPN, and I don't want this to happen. I want all traffic originating on my network to go out through the regular internet connection. I want the VPN to be used for inbound only. I don't know enough about OpenVPN to have any clue on how to do this, and the documentation is really inadequate. Googling doesn't help either, as it seems most people using it want to route all traffic through the VPN and not what I'm doing. Anyway, here is my current seutp:

OpenVPN config:

[chiefbag]

Is this question not a rehash of your original post? https://forums.gentoo.org/viewtopic-t-1068420.html

In any case adding the following to your client config will avoid the default route from being changed and all traffic routed out tun0.

[Akaihiryuu]

[Akaihiryuu]

Ok, I've decided to try to go about this a different way. Rather than only trying to do inbound via the VPN and mess with routing tables, I've decided to just concentrate on the ports that I need to be able to connect to from outside. That will be, 8022, 8080, 8443, 8888, and 8889. Is it possible to use route-nopull, and then use iptables to only route these (source) ports through the VPN, while just running everything else through my regular connection? If this works I can just add an iptables line to my NAT table and just use -m multiport --sports to match all the ports I want going through the VPN. And if I'm correct, I would do these via PREROUTING in the NAT table?

[chiefbag]

If the services you want to allow access to are running/bound to the tun0 interface then you can use an INPUT rule.
Otherwise you could use PREROUTING or FORWARD.
Don't forget to SNAT or MASQUERADE traffic -o tun0 and allow Related established on the INPUT or FORWARD, PREROUTING

[Akaihiryuu]

Here's what I've got so far. I don't want to take the server down to implement it yet because my roommate runs a muck and a couple other things that I don't want to take down unless I know what I'm doing is going to work and it will only be down for a minute. The idea here is that I will put route-nopull in openvpn, so that the default route is my regular internet connection. And then snat/masquerade only the ports I want to tun0 (which are the ones in the first two lines in postrouting - using source ports). Until I make the openvpn change, my default routes are going through tun0, so even if I try to masquerade stuff out eth1 it doesn't work (it goes out tun0 anyway). Does this look good before I try it? Is it really as simple as just using snat/masquerade to direct certain stuff to a different interface? I don't generally bind services to specific interfaces, with the exception of certain things I ONLY want available in the LAN and don't want to be accessible from outside. Anything I want accessible from outside should be bound to all interfaces. This is actually almost identical to my regular iptables setup from back when I actually had an IP address without having to use a VPN...the only tinkering I did was in the postrouting chain.

[chiefbag]

Just restart your OpenVPN client with the no route option, it will not cause any major outage.
As for iptables you should be able to insert and delete rules on the fly which can make testing easier.
Also if asking for help with rules post the actual rules rather then the -L command as it is much easier to read and comment on a rule.

[Akaihiryuu]

[Hu]

When chiefbag asked for the rules, I believe he was expecting you to post the output of iptables-save, which is also the format you should be using to load your rules. Loading via a script is error-prone and racy.

[Akaihiryuu]

Ok testing done. With route-nopull and the iptables rules, inbound connections sort of work but they are extremely slow (as in, an HTTP test page I have takes minutes to load rather than seconds). This makes no sense at all. It should either work or not. To get everything to work properly, I still need to have it pull the routes and send all outbound traffic through the tunnel. This has to be a routing table problem but I don't know where to start. The only difference between the two states are in openvpn.conf, whether or not I'm using route-nopull. Everything else including iptables rules is identical. As far as the iptables save thing, I use iptables save for my permanent rules that don't involve the tunnel at all. I didn't really want to edit those, so I'm using a script to bring up alternate rules when I'm using the tunnel (I'm not expecting this situation to be permanent). The reason I'm setting policies back and deleting things is because the script can also completely flush out iptables, and I want to start from a known state. Also, my two input multiport rules are separate, because I have another configuration where the second set of ports is blocked off. The first set of ports I always want working, the second is more conditional and sometimes I turn them off. Thus I can comment out that rule, only leaving the first.

This is the routing table where everything works (but sends all outbound traffic through the tunnel which I do not want):

[chiefbag]

[Akaihiryuu]

[chiefbag]

MASQURADE all traffic leaving tun0, it should solve a lot of your issues.

[Hu]

The machine-readable output produced by iptables-save can be saved anywhere. You can save alternate versions for VPN-up and VPN-down, then use iptables-restore to load an appropriate set. This would both let you start from a known state and avoid the race conditions I mentioned above.

[chiefbag]

Or at a minimum add the "-w" flag to your iptables command, still it won't guarantee the correct order.

[chiefbag]

Or you could add your own lock mechanism per rule like the following or shove the rules into an array and loop through.

[Hu]

That lock does not help with the race condition I meant. The lock prevents concurrent executions of iptables. My concern is that a packet which arrives while the script is executing will be processed with a partially built table that contains some rules from the script, but not all of them.

[chiefbag]

[Akaihiryuu]

Nothing I can do in iptables is going to change which interface my traffic is going out on. Right now I have everything working as far as the VPN goes. But all traffic goes out of the VPN (which is what I don't want). This is the current routing table:

[chiefbag]

[Akaihiryuu]

[chiefbag]

You definitely can't leave your default route as tun0 so you either need to use the no-pull option ( I suggest to use this method ) or fix the routing table after to change back your default route.
You may need to manually configure a route for traffic to return through tun0 that originated there.

[Hu]

What did you observe that led you to believe you would not receive inbound traffic when your default route uses your ISP? The expected results in that case are that you can receive traffic over the VPN and that, if reverse path filtering is enabled, it will likely be dropped due to a bad reverse route. If reverse path filtering is disabled (not recommended), then it should respond over the main Internet connection, which won't produce a working virtual circuit, but will produce a response.

I expect that you need to route all responses to VPN-received traffic back over the VPN.

[Akaihiryuu]

[jamapii]

The problem is,

1. you want most outbound traffic not to go through VPN

2. but inbound connections and their reply traffic must go through VPN

1 is for performance, 2 is for necessity

You can't just apply rule 1 unconditionally, because anyone connecting to the public IP address expects replies to come from this public IP address. The server, that is reached via DNAT I guess, does not know this, and sends its replies directly, and they go their usual way bypassing VPN and DNAT.

There is no simple openvpn-only configuration that can achieve this.

I had this problem before, I hat cheap NAT routers with forced NAT inside the home network, but wanted a server to be reachable from outside the NAT router.

Server and VPN endpoint on the same box, the solution was (on the server box, vtun syntax):