dual routers one OpenVPN, all other traffic 2nd router - Default Gateway - need VPN traffic sent to first router

itinfo

I have 2 PFSense routers. One for all VPN traffic (Open VPN) and the other for all internet traffic and VOIP.
VPN router is 10.10.30.16 and the General router is 10.10.30.10. The workstations have 10.10.30.10 as the default gateway.

My problem is that I cannot connect to any workstations via the VPN using RDP, unless I change the default gateway on those machines to 10.10.30.16.

I've set up 10.10.30.16 as a Gateway in 10.10.30.10 router, and I've set up static routes for all dial-in VPN traffic (10.10.35.0/24) to use Gateway 10.10.30.16.
I've added a firewall rule per https://docs.netgate.com/pfsense/en/latest/routing/bypassing-policy-routing.html
LAN, Source , Protocol IPV4, Destination 10.10.35.0/24, Port *, Gateway 10.10.30.16. It is the highest rule.

I've applied the rules and tested: does not connect. Note: I have not rebooted

I'm still unable to get to any workstation with a DG of 10.10.30.10.

Any and all ideas are helpful.

Thanks in advance

marvosa

@itinfo said in dual routers one OpenVPN, all other traffic 2nd router - Default Gateway - need VPN traffic sent to first router:

My problem is that I cannot connect to any workstations via the VPN using RDP, unless I change the default gateway on those machines to 10.10.30.16.

This is happening by design. You are unable to connect to your workstations because the general router has no route back to the VPN tunnel network, so the return traffic is being dropped. To resolve your issue, on the general router, you will need to add a static route for your VPN tunnel network with a gateway of 10.10.30.16.

itinfo

Marvosa, to address your suggestion, I did have a static routes back to the VPN tunnel - as noted,10.10.35.0/24 is the tunnel network. This did not work. Here are/were the settings:
Source: *
Protocol: IPV4*
destination: 10.10.35.0/24
Gateway: 10.10.30.16

In the end the issue was discovered by watching the System logs (Status/System Logs/Firewall/Normal View) and noticing, despite firewall rules to allow traffic to 'Pass' the 'Default Deny Rule IPV4' was preventing traffic flowing from 10.10.30.0/24 to 10.10.35.0/24.
This article speaks of this situation: https://forum.netgate.com/topic/102698/solved-firewall-pass-rule-not-working

This lead to a discussion surrounding having dual routers on the same network. In my case 10.10.30.10 and 10.10.30.16. The expectation (as I read it) is that there is a sub-net between the routers, independent of the main network. As such the 'Default Deny Rule' was taking precedent, not expecting the traffic to flow back out the LAN port. (I welcome all feedback on this reading and interpretation, as I tried many Static Routes, Firewall Rules, etc. to no avail).

Specifically I was getting Protocol: TCP-RA and TCP-SA in the Blocked Logs.

This article speaks of the System Log entries with these type of messages.
https://docs.netgate.com/pfsense/en/latest/firewall/firewall-rule-troubleshooting.html

The article speaks to Asymmetric Routing as a possible cause.

This article describes the resolution to Asymmetric Routing.

https://docs.netgate.com/pfsense/en/latest/firewall/troubleshooting-blocked-log-entries-due-to-asymmetric-routing.html

Once implemented, the issue was resolved and traffic flowed with a default gateway of 10.10.30.10.

marvosa

@itinfo said in dual routers one OpenVPN, all other traffic 2nd router - Default Gateway - need VPN traffic sent to first router:

Marvosa, to address your suggestion, I did have a static routes back to the VPN tunnel - as noted,10.10.35.0/24 is the tunnel network. This did not work. Here are/were the settings:
Source: *
Protocol: IPV4*
destination: 10.10.35.0/24
Gateway: 10.10.30.16

That is a policy route using a firewall rule , which isn't really what you wanted. At any rate, traffic appears to be flowing the way you want it, so that's all that matters.

itinfo

@marvosa Okay, to educate myself, what is it that I should have done?

marvosa

Would need to assess the network layout to look at possible solutions. However, one thing that could've been done is change LAN subnet on the VPN firewall.