0

I am using an Raspberry pi as my router to serve my pc and an ioT device. The connection diagram is as below: network setup The RPi has two ethernet port, eth1 connected to my home network 192.168.1.0/24, eth2 is connected to a switch, my pc and an ioT device is connecting to that switch. On the RPi, dnsmasq is used as DHCP and DNS server to assign ip addresses to my PC and ioT device. Openvpn client is setup to connect to the remote VPN server (corporate network). What I am trying to achieve is to only direct some of the traffic through my VPN (tun0) while most of other traffic is via my home network.

My iptables setting is as below:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i eth0 -o tun0 -d 10.1.0.0/16 -j ACCEPT
-A FORWARD -i eth0 -o tun0 -d 10.2.0.0/16 -j ACCEPT
-A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o eth1 -j ACCEPT
-A FORWARD -i eth1 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A POSTROUTING -o tun0 -j MASQUERADE
-A POSTROUTING -o eth1 -j MASQUERADE
COMMIT

When openvpn connection is established, I can talk to the corporate (from my pc) without any issue. However, all traffics are all route through the VPN tun0, and I couldn't access to the home network (from my pc). I guess that is something to do with my iptables setting, any advice?

Edit: add OpenVPN config below

dev tun
client
proto tcp
<ca>
-----BEGIN CERTIFICATE-----
==
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
==
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
==
-----END PRIVATE KEY-----
</key>
remote-cert-eku "TLS Web Server Authentication"
remote example-domain.com 443

route-nopull
route 10.1.0.0 255.255.0.0 10.0.0.1
route 10.2.0.0 255.255.0.0 10.0.0.1

dhcp-option DNS 10.1.0.253
dhcp-option DNS 10.1.0.254
dhcp-option WINS 10.1.0.253
dhcp-option WINS 10.1.0.254
dhcp-option DOMAIN internal.example-domain.com
block-outside-dns

redirect-gateway def1
persist-key
persist-tun
verb 3
mute 20
keepalive 10 60
cipher AES-256-CBC
auth SHA256
float
reneg-sec 3660
nobind
mute-replay-warnings
auth-user-pass
Improve this question
2
  • 1
    This routing is configured within the VPN settings. Please post your OpenVPN client configuration file, redacting the details for lines starting remote, auth-user-pass, and removing entire blocks enclosed in angle-bracketed sections (for example <ca>...</ca>)
    – Chris Davies
    Commented Aug 26, 2021 at 12:44
  • Thanks @roaima I've added my OpenVPN config on the post, although I don't really understand the connection between my OpenVPN config and the iptable routing.
    – cityzz
    Commented Aug 27, 2021 at 12:39

1 Answer 1

Reset to default
1

The entry in your OpenVPN configuration file that's responsible for handling the default routing is this one

redirect-gateway def1

It tells the OpenVPN client to redirect all traffic through the OpenVPN gateway.

If you want to control which routes are sent through the OpenVPN tunnel the keyword is route. It can be repeated multiple times, once per subnet. For example, to send everything in the 10.0.0.0/8 and 192.168.77.0/24 subnets across the tunnel, while leaving everything else to route via your LAN and LAN gateway you could use this configuration setting instead of the redirect-gateway one

# route network/IP [netmask] [gateway] [metric]
route 10.0.0.0 255.0.0.0
route 192.168.77.0 255.255.255.0

In your case the routing is already specified, so you simply need to comment out the redirect-gateway line and restart your VPN connection.

Improve this answer
5
  • Cool, thanks. Is that mean if I have those iptable forward rules, I do not need to us route keyword in the OpenVPN config?
    – cityzz
    Commented Aug 27, 2021 at 17:46
  • You've got three default actions of ACCEPT, so none of your explicit ACCEPT rules are required. You can use the MASQUERADE rules if you want to, but you shouldn't need those either. I'd be inclined to remove the whole lot and confirm it still works, but be warned that will still leave your system wide open to anything that can poke it directly (including systems the other end of the OpenVPN link)
    – Chris Davies
    Commented Aug 27, 2021 at 18:11
  • 1
    Thanks I think you are right. I've removed all the ACCEPT rules in the filter table, and it still works. The only things matters are the MASQUERADE rules, without them, I couldn't talk to the corporate network. I will refine the rules to prevent the other end of OpenVPN link to poke my devices, thanks.
    – cityzz
    Commented Aug 27, 2021 at 19:35
  • I've experienced a problem with https services on corporate network. Without redirect-gateway def1 I kept getting connection refused on https services while the http services are fine, any idea how to get around that issue?
    – cityzz
    Commented Aug 29, 2021 at 15:19
  • The redirect-gateway option controls routing, not ports. If removing that option breaks something you need to look at the routing for the "something". It might be a web proxy, for example, and nothing directly to do with the https service itself
    – Chris Davies
    Commented Aug 29, 2021 at 18:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .