Any way to disable the automatic gateway creation?
Hi there, i'll try to keep my topic as small as possible, whilst still providing enough details.
I've been having issues with the dynamic gateways that pfsense seems to create for every OpenVPN server and client you create.
This has been going on for quite some months actually, I've been searching on google, on these forums, but haven't found a conclusive answer.
I know that you can edit the files yourself, but that would defeat the purpose .
Now, the problem is that for my OpenVPN server and client, it doesn't seem to send a gateway address, so the gateway address that gets added is "255.255.255.0".
Obviously that does create errors, but that's not the only issue I have.
For as long as I've been having those problems, this message pops up every single second in my system logs.
kernel: arpresolve: can't allocate llinfo for 255.255.255.0
Looking at this reference thread http://forum.pfsense.org/index.php?topic=38438.0 , i checked the /tmp/*_routers file and sure enough,
there were 3 files, 2 for the vpns, and 1 for my PPPoE WAN.
those 2 vpn ones had 255.255.255.0 in them, even though the vpns themselves work just fine.
So my final question actually is, is it possible to disable the automatic gateway creation for OpenVPN besides editing the files directly?
edit: I should note though, that before pfsense would let me access the vpn from other pc's in the LAN subnet, i'd have to add some outbound NAT lines. Other than that (and the obvious question/problem at hand), everything works just fine.
Do you have these OpenVPN interfaces assigned as OPT interfaces?
Are these OpenVPN interfaces using tun or tap mode?
They are assigned as OPT intefaces (renamed them accordingly), but I didn't let them set up an IP,
seeing as they get one from the server.
edit: So both have None/None for ipv4 and ipv6, but are enabled so i can have firewall rules for the VPN's networks
They're both using TAP. I've had way too many issues with TUN, so i went with TAP.
I do wonder if the fact that i enabled cryptodev has anything to do with it (it's running on a AMD Fusion e-350)
Config for the client
dev ovpnc1 dev-type tap dev-node /dev/tap1 writepid /var/run/openvpn_client1.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp cipher AES-256-CBC up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 220.127.116.11 engine cryptodev tls-client client lport 0 management /var/etc/openvpn/client1.sock unix remote 18.104.22.168 123 ifconfig 192.0.2.2 192.0.2.1 ca /var/etc/openvpn/client1.ca cert /var/etc/openvpn/client1.cert key /var/etc/openvpn/client1.key tls-auth /var/etc/openvpn/client1.tls-auth 1
config for the server
dev ovpns3 dev-type tap dev-node /dev/tap3 writepid /var/run/openvpn_server3.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp cipher AES-128-CBC up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 22.214.171.124 engine cryptodev tls-server server 172.16.100.0 255.255.255.0 server-ipv6 2001:6f8:142f:4::/64 client-config-dir /var/etc/openvpn-csc lport 53 management /var/etc/openvpn/server3.sock unix push "route 192.168.8.0 255.255.252.0" push "route-ipv6 2001:6f8:142f::1/64" client-to-client ca /var/etc/openvpn/server3.ca cert /var/etc/openvpn/server3.cert key /var/etc/openvpn/server3.key dh /etc/dh-parameters.1024 tls-auth /var/etc/openvpn/server3.tls-auth 0 comp-lzo persist-remote-ip float
edit: oh, and here's a screenshot from the status tab http://www.wrongplace.be/files/OpenVPN.status.png
Well tap is likely the reason you're getting that error, tun has way less problems, not sure what you've had with it before, but with pfSense, tun is by far less problematic.
And you don't need to assign them, if you don't assign them, then you don't get the gateways.
To put it bluntly, if i don't assign them, i won't be able to apply firewall rules for them. (Well i could add floating rules but that's beside the point)
That's what the "openvpn" tab is for - you can apply rules there, and restrict them by subnet rather than separate interfaces.
After some additional fiddling with outbound NAT it finally seems to work, in combination with the "just use the openvpn tab".
Had to reboot the machine before the messages went away though.