Routing IPSec to a VLAN

RouterOS General
1

I have a bit of a conundrum, and I am certain it is the result of some obvious problem I keep overlooking. I have a switch segmented into three VLANs:

  • BASE_VLAN for management.
  • COMMON_VLAN for internal systems.
  • PATIO_VLAN for external systems.

The switch has a single trunk line to an Internet-facing router (ref. the setup in this post). I configured IPSec with L2TP on the router, and I found that while a connected device can reach the Internet through the VPN, it cannot reach anything on the VLANs. I tried adding an explicit route to the PPP secret record, but as I suspected this did not help. I also tried poking holes for all dynamic interfaces (just as a test) in the input and forward chains on the router’s firewall, but this also did not help. COMMON_VLAN uses the subnet 192.168.2.0/24 and the router has a management interface at 192.168.2.1, which VPN clients can reach once connected. However, any traffic bound for the switch apparently vanishes into the ether.

I have attached sanitized configuration files that I hope will be useful. sfp10 is the trunk line from the switch to the router, and it terminates at ether2.
switch.rsc (3.06 KB)
router.rsc (4.86 KB)

2

This rule allows access from VPN to COMMON_VLAN:

/ip firewall filter
add action=accept chain=forward comment="VPN to COMMON_VLAN" connection-state=new in-interface-list=dynamic out-interface=COMMON_VLAN src-address=192.168.2.0/24

But the problem is, since you use same pool for COMMON_VLAN and VPN clients, devices in COMMON_VLAN will expect VPN client’s address to be directly reachable (answer ARP requests) and it won’t happen. You can either use different subnet or you’ll have to set arp=proxy-arp for COMMON_VLAN interface.

Then this rule doesn’t allow access only to internet as the comment says, but from VPN to anywhere:

/ip firewall filter
add action=accept chain=forward comment="VPN to Internet" in-interface-list=dynamic src-address=192.168.2.0/24

COMMON_VLAN still has the same problem, but communication with others should work, when it’s initiated from VPN client. Make sure that it’s not problem with firewall on target devices, i.e. that they accept connections from other subnets.

3

Changing the IP address pool fixed the problem. I also removed the firewall rule that ostensibly allowed Internet access to the VPN and just reconfigured the client not to send all traffic to the VPN. The only purpose of this connection is to get access to internal systems from the outside. It is not intended to be a full tunnel for regular Internet use.