subnet tunnel all traffic via OpenVPN

loffovyl

Hi All,

Seeking your expert advise for probably unusual type of configuration needed.
In simple terms - LAN hosts have set default gateway to OpenVPN server, which has connected OpenVPN client which is to be used as exit point towards internet for these LAN hosts behind OpenVPN server.

LAN<--->OpenVPN server<---_tunnel_to_client--->OpenVPN client <----> internet.

In exact configuration, the OpenVPN server is Docker container and more exact configuration looks like below, though it doesn't probably change anything for the problem am facing:

LAN<--->Docker Host<--->OpenVPN server (in container)<---_tunnel_to_client_via_internet_--->OpenVPN client <----> router <---> internet.

There is subnet connected to OpenVPN client which is already reachable for LAN hosts (push entries, etc.)

What works:
- LAN hosts have Docker Host set as default gateway.
- Docker Host has set using iproute2 (custom routing table) default gateway for LAN hosts to be OpenVPN server (source based routing /rule targeting specific table and that table has default gateway entry set on OpenVPN server).

What doesn't work:
- OpenVPN server has set routing in same way as above with the only difference being default gateway IP to be in this case remote OpenVPN client - same logic as all other subnets exposed by OpenVPN client and to which traffic works.
- Traffic gets up to OpenVPN server and seems to be going through "FORWARDING" though probably being dropped by OpenVPN code.

Feeling is that since dst IP is anything in internet, packets are dropped as some configuration entry is missing on OpenVPN side allowing to forward the traffic.
For sake of try, I did also SNAT traffic on Docker Host which reaches OpenVPN Server (container) to be on container subnet - did't help.

Why am I trying to get through OpenVPN client to internet and why it is not that LAN is behind client and remote internet GW/behind tunnel is the OpenVPN server? This layout comes out of situation that OpenVPN server is server for multiple locations and in this case, for only specific hosts in LAN traffic needs to be pushed out via different egress point to internet.
Is this possible at all with OpenVPN?

I'd prefer to avoid setting up additional pair of OpenVPN client/server to have server at remote location and local client to allow traffic.

I want to KISS (keep it stupid simple) and any suggestion re how to simplify it - are more than welcome.

Thank you in advance for help.

loffovyl

After long hours of scratching my head and troubleshooting via different approaches, like taking it via ipip tunnel between default gateway for whole LAN doing source based routing and pushing it via ipip tunnel to the OpeVPN client, terminated on other interface - it did happen that problem could be due to rp_filtering being enabled on that OpenVPN host. Given the complexity of setting up dedicated routing table on routers between src in LAN and OpenVPN gateway (I've skipped above for the sake of clear picture of the logic), it happen that using ipip tunnel is the KISS approach - the least of modifications in routing and easiest to troubleshoot.
The downside is the increased packet size but this I might accept - I'll see in next days.

Should one run into troubles that packets arrive on interface but are not forwarded, outside of FW rules, ttl, etc. it's worth checking rp_filter setting. In my case I had it strict ("1") and that was causing packets to be silently dropped.
Options around are:
a) adding more specific routing for revers traffic (in my case I had same IP from LAN host going out of the ipip tunnel as is accessible via OpenVPN) - preferred solution as is clean,
b) switching to loose rp_filter ("2"), as I wouldn't advise to disable rp_filtering. Even with loose option one exposes itself to DDoS.

Good luck!

TinCanTech

loffovyl wrote Seeking your expert advise for probably unusual type of configuration

Your Openvpn configuration files are still missing. This thread has little context without them.

loffovyl

TinCanTech wrote
loffovyl wrote Seeking your expert advise for probably unusual type of configuration
Your Openvpn configuration files are still missing. This thread has little context without them.

Thanks, the question was theoretical - if that logic is possible within OpenVPN at all - if yes, then what's required to be in the configuration?
I can set it then accordingly to advisory. Testing with iroute/push didn't seem to help, given the "reverse" direction for the traffic I needed.
The KISS approach with IPIP tunnel resolved the problem as it seemed like packets were dropped at OpenVPN logic level, probably due to IP Spoofing logic (or maybe because I didn't manually relax it for OpenVPN interface). By default I have strict as default for all interfaces.

ordex

Do you have a "iroute" for the VPN client saying that "everything" has to go through it?
iroutes are used to tell the OpenVPN server process which client to route traffic to.

loffovyl

@ordex, the setup is that the traffic would need to be going out through the _client_ and arriving from server LAN side, though only for selected IP.
Not sure how to achieve this, as can't set it up as server wide, though would need to allow that.
Any hints are welcome.

ordex

@loffovyl like mentioned above, when a client is expected to be responsible for client going to IPs other than the one being assigned to it (i.e. to reach the LAN behind the client or even to use the client as Internet gateway) you need to configure specific "iroutes" in the CCD file of that client.

The iroute will tell the OpenVPN server: "when a packet is directed to x.x.x.x, please send it to client Y".

loffovyl

Thanks @ordex.

Let me maybe better explain the situation.
# simplified network diagram

LAN<--->OpenVPN server<---_tunnel_to_client--->OpenVPN clientA <----> internet.
                                                               <----> clientA LAN
                      <---_tunnel_from_another_client----> OpenVPN clientB <---> clientB LAN

All clients connected to OVPN Server:
a) provide access to LAN behind Server and LAN behind other clients via OVPN Server - that works
b) provide access to Internet directly (no VPN involved) - that works too.
Server provides access to LAN clients directly via it's internet uplink.

_only_ specific IP/client from server side LAN needs to be pushed out via VPN back to clientA to use it's internet access.

Therefore it doesn't look like setting up iroute, which <<tell the OpenVPN server: "when a packet is directed to x.x.x.x, please send it to client Y".>> is the right thing to do as it would then cause other packets destined to internet (0.0.0.0/0) to be sent via clientA? This wouldn't work.

In my earlier efforts to get that running, as essential element, I've used PBR and did set appropriate ip rules at kernel level. It took me to the level that sounded like it was being dropped as reported earlier, then moved to ip-ip tunnel and got it working after relaxing rp_filter.
I might give it another try with OVPN and relaxed rp_filter to confirm if this wasn't the killer, though given iroute explanation it doesn't seem like it would work. I'm keen to try though for the sake of confirming it.

Thanks again for help!

ordex

loffovyl wrote Thanks @ordex.

Let me maybe better explain the situation.
# simplified network diagram
LAN<--->OpenVPN server<---_tunnel_to_client--->OpenVPN clientA <----> internet.
                                                               <----> clientA LAN
                      <---_tunnel_from_another_client----> OpenVPN clientB <---> clientB LAN
All clients connected to OVPN Server:
a) provide access to LAN behind Server and LAN behind other clients via OVPN Server - that works
b) provide access to Internet directly (no VPN involved) - that works too.
Server provides access to LAN clients directly via it's internet uplink.

_only_ specific IP/client from server side LAN needs to be pushed out via VPN back to clientA to use it's internet access.

Therefore it doesn't look like setting up iroute, which <<tell the OpenVPN server: "when a packet is directed to x.x.x.x, please send it to client Y".>> is the right thing to do as it would then cause other packets destined to internet (0.0.0.0/0) to be sent via clientA? This wouldn't work.

In my earlier efforts to get that running, as essential element, I've used PBR and did set appropriate ip rules at kernel level. It took me to the level that sounded like it was being dropped as reported earlier, then moved to ip-ip tunnel and got it working after relaxing rp_filter.
I might give it another try with OVPN and relaxed rp_filter to confirm if this wasn't the killer, though given iroute explanation it doesn't seem like it would work. I'm keen to try though for the sake of confirming it.

Thanks again for help!

I think I got it :-)

So, to summarise with my words: you want clients in the server LAN to access the Internet directly, without going through the VPN, except for a bunch of well defined clients. The latter have to go through the VPN.

Assuming I understood it right, here you require policy routing.

What I would do is:
1. create a new routing table on the server (tableA)
2. using 'ip route' add a default route via clientA to tableA
3. using 'ip rule' or 'ip rule + iptables' (depends on your requirements) instruct traffic coming from the specified clients to use tableA

All other traffic generated on the server (or coming from other clients) will not be affected and will still go out via the server Internet uplink.

Does it make sense?

ordex

Of course you can replicate the same for clientB, assuming that you have specific clients that have to go through clientA and through clientB

loffovyl

The PBR portion was the easy one for me (setting up ip rules, routing table, etc.) - this worked. What didn't work is that somehow it seemed like it was blocked at OpenVPN level.
If there's believe it should work - I'd be happy to re-run tests, though gotta say that am now cheating OpenVPN in a way that I've built ip-ip tunnel via same OpenVPN tunnel, just using the IPs on interfaces of VPN Server/ VPN Client - so OpenVPN is happy, as it doesn't look into payload and ip-ip does the rest of the job. Obviously, PBR had to be set with similar logic as earlier for OpenVPN when it didn't work.

Thanks!

ordex

loffovyl wrote The PBR portion was the easy one for me (setting up ip rules, routing table, etc.) - this worked. What didn't work is that somehow it seemed like it was blocked at OpenVPN level.

It is not exactly clear to me what is not working. If you want to deepen, can you please provide an example of what test you performed that showed to be not working?

If you are talking about "connecting to/from a host behind a VPN client", that requires setting up an iroute on the server.

Pippin

_only_ specific IP/client from server side LAN needs to be pushed out via VPN back to clientA to use it's internet access.

Maybe this quote clears it up?

Here is one similar example, difference is, all traffic goes through a client as gateway and it's from other client instead of specific host behind the server:
https://forums.openvpn.net/viewtopic.php?f=6&t=27421