[BUG?] Interface name cause routing issue
-
Hi to all.
schematic setup:
net vpn: 10.29.46.0/28
gw 192.168.x.5 pfsense 2.2.5 router1| | V
| | P
| | N
| |192.168.x.148 pfsense 2.2.5 router2
Router2 have router1 like its gateway. When i setup a vpn, routing change on router2 and this rule be added:
192.168.x.5 10.29.46.1 UGHS ovpnc4
This breaks the connection because this traffic should not pass through the VPN tunnel!I've tried to check "Don't pull routes….." from openvpn client setup, but it doesnt work.
In router 1 i have explicitly blocked this traffic, because it shouldn't pass trough vpn, but from its own interface (192.168.x.148)
Is this openvpn behavior normal? And if yes, how i could prevent this?EDIT2: This issue appear when i assign ovpncX to an interface. This not happened in another openvpn setup, the only difference are the server mode: remote access works, but shared key not work.. i will try to edit this setup to see what happen
EDIT3: Removing and reassigning the interface solved the issue... but... if i rename the interface in "VPN_WIBRI" the issue (and the route above) shows up. I thing this is a bug :o very strange bug since interface name should be only descriptive :o
-
The name of the interface has no impact on routing. Renaming it and applying that change will reconnect it though. You have something in routing configured wrong where you end up with a wrong route like that. That 192.168.x.5 is configured somewhere with a route. If not within OpenVPN itself, maybe as a DNS server IP specifying the VPN gateway.
-
@cmb:
The name of the interface has no impact on routing.
That 's what I thought too ;D before this!
@cmb:That 192.168.x.5 is configured somewhere with a route. If not within OpenVPN itself, maybe as a DNS server IP specifying the VPN gateway.
In normal "netstat -rn" i cant't see 192.168.x.5 (maybe because monitor configured in routing is itself and it isn't default router), but it is WAN1 gateway in a multi-wan setup, it's also one of DNSs configured in "general setup" and it is the server of my VPN.
This routing issue appear only when my interface name have that name, maybe because of "_", i dont know why. If i had time i will try to replicate this issue on a VM.