Route incoming traffic through VPN-tunnel to a LAN interface

buksa · January 15, 2022, 3:33pm

Home I have:

OpenWRT:

OpenVPN via vpn0 interface --> OpenVPN-server (10.8.0.0/24). (Through WAN physical interface)
VLAN50-interface with 192.168.50.0/24, routed all traffic through the VPN.
VLAN50-interface has default gw 192.168.50.1. (Physical ethernet interface, separate from physical WAN interface above).
tun0 on OpenWRT has the dynamic assigned IP 10.8.0.2 and it's the only client connected to the VPN-server.
Firewall rule which accepts traffic from VLAN50 --> vpn0.
(Everything works as it should this one way, I reach both the 192.168.1.0/24 network and getting a route through WAN and to the internett on the other side from home).

Remote server/VM (Ubuntu) I have:

VPN-server:

With interface tun0 (<-- OpenWRT-client tunneled home 10.8.0.0/24, just to picture things more easily).
On same VPN-server I have eth #2 iface on network 192.168.1.0/24 with static IP 192.168.1.60 and 192.168.1.1 as default gw (pfsense VM on same network).
I've added 192.168.1.60 as some additional gw address on my pfsense firewall as well.
Added a static route to 10.8.0.0/24 through that IP. So pfsense knows where to send traffic with destination 10.8.0.0/24.
I can ping 10.8.0.2 from 192.168.1.0/24. So far so good.
I cannot ping 192.168.50.0/24 from 192.168.1.0/24.
I have added 2 firewall rules: Allow traffic from 192.168.1.0/24 --> both 10.8.0.0/24 and to 192.168.50.0/24 in pfsense.

This is the further issue I cannot seem to resolve:

I want to be able to reach 192.168.50.0/24 from 192.168.1.0/24.

By this I am certain I need to add a route and a rule on the OpenWRT firewall to get this working. I've tried to add a firewall rule that accepts traffic from interface vpn0 --> interface VLAN50 (192.168.50.0/24). But I'm not quite sure how to route this in OpenWRT. Since these interfaces both are on the same device, I'm not sure how OpenWRT handles this. How do I add a route, and which networks do I need to add a route between, to get this correct and avoid adding loops? Is there anything else maybe?

buksa · January 15, 2022, 5:26pm

... Just added a route on the VPN-server, which I also figured would be smart:
destination network 192.168.50.0/24 gw 10.8.0.2
Don't know if that would be correct/necessary. Still no ping reply from 192.168.50.10 (which is the PC I'm currently on). Or for that matter, from 192.168.50.1.

I also just in case, added static route on pfsense on the server network:
Destination network 192.168.50.0/24 gw 192.168.1.60

Now at least both the firewall and OpenVPN server knows where to find the network. And as of what I understand they both reach 10.8.0.2. Which is tun0/vpn0 on my OpenWRT router here at home. Where it seems to be stopping.

psherman · January 15, 2022, 5:42pm

Please copy the output of the following commands and post it here using the "Preformatted text </> " button:

Remember to redact passwords, MAC addresses and any public IP addresses you may have:

cat /etc/config/network
cat /etc/config/firewall

buksa · January 16, 2022, 10:09am

cat /etc/config/network:

config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'

config globals 'globals'
option ula_prefix 'fd99:cecf:f32b::/48'

config device
option name 'br-lan'
option type 'bridge'
list ports 'eth0'

config interface 'lan'
option device 'br-lan'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option ipaddr '192.168.2.1'

config interface 'wan'
option proto 'dhcp'
option device 'eth1'
option peerdns '0'
list dns '8.8.8.8'
list dns '8.8.4.4'

config route
option interface 'lan'
option netmask '255.255.255.0'
option gateway '10.8.0.1'
option target '192.168.1.0/24'

config interface 'vpn0'
option proto 'none'
option device 'tun0'

config device
option type '8021q'
option ifname 'eth0'
option vid '50'
option name 'eth0.50'

config interface 'VLAN50'
option proto 'static'
option device 'eth0.50'
option ipaddr '192.168.50.1'
option netmask '255.255.255.0'

config device
option type '8021q'
option ifname 'eth0'
option vid '20'
option name 'eth0.20'

config interface 'VLAN20'
option proto 'static'
option device 'eth0.20'
option ipaddr '192.168.20.1'
option netmask '255.255.255.0'

cat /etc/config/firewall:

config defaults
option input 'ACCEPT'
option output 'ACCEPT'
option synflood_protect '1'
option forward 'REJECT'

config zone
option name 'no_vpn'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'VLAN20'

config zone
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option name 'lan'
list network 'VLAN50'

config zone
option name 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
list network 'wan'
list network 'wan6'

config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'

config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'

config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'

config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'

config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'

config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'

config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'

config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option proto 'esp'
option target 'ACCEPT'
option dest 'lan'

config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
option dest 'lan'

config rule
option name 'Support-UDP-Traceroute'
option src 'wan'
option dest_port '33434:33689'
option proto 'udp'
option family 'ipv4'
option target 'REJECT'
option enabled 'false'

config include
option path '/etc/firewall.user'
option reload '1'

config zone 'vpn'
option name 'vpn'
option network 'vpn0'
option input 'ACCEPT'
option forward 'REJECT'
option output 'ACCEPT'
option masq '1'

config forwarding
option dest 'wan'
option src 'lan'

config forwarding
option src 'lan'
option dest 'vpn'

config forwarding
option src 'vpn'
option dest 'lan'

config forwarding
option src 'no_vpn'
option dest 'wan'

config rule
option name 'From Proxmox'
option family 'ipv4'
list proto 'all'
option src 'vpn'
option dest 'lan'
option target 'ACCEPT'

buksa · January 16, 2022, 10:24am

Just as a little additional information, on my PFsense side of things:

gws

psherman · January 16, 2022, 4:47pm

Is the pfsense system on the same physical network as the OpenWrt router, or is that simply showing the remote side of this VPN tunnel?

buksa · January 17, 2022, 2:56pm

PFsense is on the remote side of the tunnel.

buksa · January 17, 2022, 7:09pm

While that being said, it NATs the OpenVPN tunnel through 1194 UPD --> 192.168.1.60 which is the OpenVPN server (Ubuntu).

psherman · January 17, 2022, 10:52pm

Remove this... it is already handled by the forwarding rule that allows vpn > lan forwarding.

Let's take a look at the OpenVPN client and server configurations.

buksa · January 19, 2022, 5:13pm

psherman, thanks for your time.

This is the OpenVPN client config:
(I haven't pasted server url or keys in this paste-in)

client
dev tun
proto udp
remote *url to server here* 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
ignore-unknown-option block-outside-dns
block-outside-dns
verb 3
<ca>
-----BEGIN CERTIFICATE-----
A long key here...
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
A long key here...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
A long key here...
-----END PRIVATE KEY-----
</key>
<tls-crypt>
-----BEGIN OpenVPN Static key V1-----
a long key here....
-----END OpenVPN Static key V1-----
</tls-crypt>

OpenVPN server config-file:

route 10.8.0.0 255.255.255.0 192.168.1.1
local 192.168.1.60
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
ifconfig-pool-persist ipp.txt
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
crl-verify crl.pem
sndbuf 0
rcvbuf 0
push "sndbuf 393216"
push "rcvbuf 393216"

Ubuntu static routes (VM running OpenVPN server):

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 ens18
10.8.0.0        0.0.0.0         255.255.255.0   U         0 0          0 tun0
192.168.0.0     192.168.1.1     255.255.255.0   UG        0 0          0 ens18
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 ens18

I also have this in my /etc/sysctl.conf to allow routing/forwarding of ipv4:

net.ipv4.ip_forward=1

You said:

config rule
option name 'From Proxmox'
option family 'ipv4'
list proto 'all'
option src 'vpn'
option dest 'lan'
option target 'ACCEPT'

Remove this... it is already handled by the forwarding rule that allows vpn > lan forwarding.

Will that rule also accept traffic the other way? Since that rule accepts traffic from lan zone to vpn zone?

buksa · January 29, 2022, 10:24am

I haven't solved this yet

psherman · January 29, 2022, 5:08pm

Sorry for the delay here.

I don't think this is right, although maybe the proxmox configuration means that this needs to be a bit different.

Usually, I have a line in my OpenVPN server config that pushes the route to the client, and another for the DNS:

        push 'route 10.0.1.0 255.255.255.0'
        push 'dhcp-option DNS 10.0.1.1'

The above, from my server config, pushes the route of the LAN (10.0.1.0/24) to the client, and sets the DNS server to my main router (10.0.1.1).

The "From Proxmox" rule you have defined explicitly has a source of vpn and a destination of lan. The forwarding rule that has the same source and destination already does this exact thing. The "From Proxmox" rule is redundant.
In general, the rules that allow forwarding between two zones (say a > b) will also allow the return traffic (so b > a when b is replying).

buksa · March 13, 2022, 10:55am

@psherman , thanks for helping here and your time consumtion - I have read your reply, and will come back to you very soon. Sorry for my very late reply. Feel that I am close to a solution.

stephendt · April 5, 2022, 3:15am

Did you have any luck with this? I am in a similar predicament. Looking to port forward through my cloud-hosted PFSense router to a local address behind my OpenWrt router via a VPN client connection.

buksa · April 19, 2022, 6:23pm

Hello, @psherman

I am having a bit more look into this again.

It is possible I am misreading you at some point. But just to clarify; I have no issues with traffic being initiated from inside of my (home/OpenWRT) LAN and through the tunnell. I reach my external LAN (behind the OpenVPN server and PFsense) perfectly fine. With every services I need. Not quite sure if my OpenVPN server is running the traffic through NAT or routes, though. Maybe that has anything to do with this whole mix as well.
--->
EDITED AFTER I WROTE THE LAST WORD UNDERNEATH: Yeah. Why would I need static ROUTES defined on the OpenVPN server if traffic isn't being routed anyway? Then it has nothing to say, except of what is inside the openvpn config file? Or am I wrong here?

Anyways.

Usually, I have a line in my OpenVPN server config that pushes the route to the client, and another for the DNS:

    push 'route 10.0.1.0 255.255.255.0'
    push 'dhcp-option DNS 10.0.1.1'

When you are saying that it pushes it to the clients: You're referring to the VPN clients right? Because the traffic FROM the client/OpenWRT side of things, are just fine. As mentioned.

The "From Proxmox" rule you have defined explicitly has a source of vpn and a destination of lan. The forwarding rule that has the same source and destination already does this exact thing. The "From Proxmox" rule is redundant.
In general, the rules that allow forwarding between two zones (say a > b) will also allow the return traffic (so b > a when b is replying).

And also, am I reading you right and you're applying that the rule that allows traffic from my LAN/OpenWRT and to the tunneling interface also allows traffic initiated from the external/VPN-network? I sure hope not! That would've allowed anything back from your every WAN and in to the local network, if working that way. You have to have one rule per direction, if you want to allow initiated traffic from both sides. I strongly assume.

I am getting return-packets from whatever PID initiates traffic from my (Home) LAN and --> through the VPN-server --> The Proxmox server/PFsense LAN... That works.

The only thing that doesn't, is to reach my (home/OpenWRT) LAN from the OpenVPN-server - through the tunnel - through the OpenWRT fw - to the whatever VLAN I define.

I did some research again the other day, and I found something interesting. Maybe you guys can have a look and see if this is something you have experience with: https://backreference.org/2009/11/15/openvpn-and-iroute/

This has examples in it, and explains a lot about what routes that shall be used. And that iroute line. And why it matters. The thing is just that this postings from 2009. Much have probably changed in OpenVPN software since then. And it's a little unwise to follow that old articles when it comes to network security in general

@stephendt ; I haven't tried this yet. But maybe I'll try it soon - In combination with a static route or two.

I have understood this much:

I reach the subnet defined on the OpenVPN-server's tun-adapter (which is the default one's being used: 10.8.0.0/24) from the subnet which is on the OpenVPN-serves' NIC - Which again is the LAN with the reset of my VMs on, all behind the PFSense.
If I try to ping one jump further, which will then be the 10.8.0.0/24-address assigned to the tun0-device on my OpenWRT firewall, I'm not getting there.

Which means, that it's the jump between 10.8.0.1 OpenVPN-server and OpenWRTs tun0 with 10.8.0.x.
In theory I should be able to ping the tun0 of my OpenWRT making sure I'm pinging from the right interface, on the OpenVPN-server. If not, there should be a fundamental issue. For instance some accept-rule missing on my OpenWRT. Or some obvious config blocking all traffic that way around. Maybe I'm scoping within the size of the issue. I know I remembered to enable kernel IP forwarding. But still I suspect that this has something to do with the OpenVPN NAT. I have no running software firewall on that VM.

My thoughts next will be to try to follow the advice of the OpenVPN server config change as in the link above. Next, find the correct static routes to define on the OpenVPN server kernel. I think that pinging the mentioned IP again, but first defining which source interface/IP-address for the ping I might get an idea of what route is missing. At least as the first step further.

Because so far I'm actually not sure from which of the interfaces I tried to ping from.
Maybe it tries both, as default ..? I don't know.

Give me all your thoughts and feedback here. I appreciate it. And don't worry - I will take it all in the best of ways.

Cheers.

stephendt · April 19, 2022, 11:54pm

Thanks for the update. For what it's worth, I did end up being able to work around this issue - but it ended in the form of me setting up a completely separate OpenWrt VM (DHCP disabled, desired clients statically assigned an IP / Gateway), setting up a full WireGuard tunnel to my VPS, and then doing port forwarding from there.

It's messy but it does work. My next step is playing around with VLANs to achieve the same thing on my primary router, but I have something working for now so I can relax a bit.

buksa · May 18, 2022, 7:02pm

Hi @stephendt and @psherman

I have reached the conclusion to give this up - And rather try to use my PFSense firewall as an OpenVPN server instead of running a dedicated Linux VM with a server running on it.

It might be a more correct configured server without too much trouble - It has a good GUI and a good rep. And if I'm lucky, two-way traffic might be working from day one without any special needs.

I wouldn't consider this thread as 'solved', but I don't feel like pursuing a solution any further. So in some what way I need to "end" it. Do I have to mark it as 'solved' ?

system · May 28, 2022, 7:03pm

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.