Php: : Could not find IPv4 gateway for interface (opt1).
-
Do you have a default gateway? (See System -> Routing click on Gateways tab)
What gateways do you (should you) have?
-
I have a default gateway for the WAN as usual.
For the OPT1 a OPT1_VPNV6 gateway is automatically created. IPv6 is disabled in system/advanced and on the Interfaces.
-
For the OPT1 a OPT1_VPNV6 gateway is automatically created. IPv6 is disabled in system/advanced and on the Interfaces.
Your OPT1 is a VPN? If so, which type?
I have an OpenVPN server defined on one of my pfSense boxes and can't see a place on the appropriate Interface page for disabling IPv6.
-
From the post, I guess you have WAN as the real interface that sits on a real network and receives incoming connects from OpenVPN clients. You have added an OPT1 interface for the OpenVPN server, which normally creates 2 "virtual" gateway entries like OPT1_VPNV4 and OPT1_VPNV6. These get created even though the interface settings for OPT1 say IPv4 Configuration Type "None" and IPv6 Configuration Type "None" - IMHO it doesn't respect IPV6 setting in System Advanced. I don't think the code that makes these "virtual" gateway entries looks deeply into the OpenVPN server config that corresponds to the interface. If it did, it could look at IPv4 Tunnel Network and IPv6 Tunnel Network settings - for any that are blank, it could decide not to make a "virtual" gateway entry.
But I don't think the IPv6 "virtual" gateway entry would be breaking things.
Have you tried the latest snapshot? There have been a few mods to code in this area recently. -
Phil,
You are correct. Single WAN real interface, terminating OPENVPN clients. OPT1 interface is assigned to OVPN interface.
I have only one virtual gateway.I'm almost on the latest snapshot. (built on Wed Jan 9 11:13:00 EST 2013)
The server is a test server, so I'm happy to give the ip and login if you want.
-
After further testing, it must be a other problem related with DNS.
Uninstalled Squid there is no DN resolve anymore.Will do a clean install later today.
-
Done a fresh install and updated to the latest snapshot.
Still have the same error message and no ping to the the default gateway of the WAN interface.
All pass rules, standard NAT… -
Can someone tell me difference between the two snapshots in respect to OPENVPN, assigned OPT interfaces and gateway assignments? :(
2.1-BETA0 (i386)
built on Sun Dec 9 04:41:14 EST 2012
FreeBSD 8.3-RELEASE-p52.1-BETA1 (i386)
built on Tue Jan 22 05:52:29 EST 2013
FreeBSD 8.3-RELEASE-p5You are on the latest version.
-
Just to keep this thread going and under attention. :-X
php: : Could not find IPv4 gateway for interface (opt2).
with
2.1-BETA1 (i386)
built on Thu Jan 24 19:53:59 EST 2013
FreeBSD 8.3-RELEASE-p5I going to roll back to the 7 dec 2012 snapshot!
-
Does the proper 'gateway' IP show up under Status > Gateways?
The version of OpenVPN changed recently but it shouldn't have changed anything to do with our gateways.
From Dec 9 to Jan 22 is a very long time in terms of 2.1 development. Many, many things changed between those times.
-
This commit seems like the most possible one:
https://github.com/bsdperimeter/pfsense/commit/c822154cf0879ee88c20220706485096e3b5e48c
Now, if you assign an interface to an OpenVPN server, a gateway is also created to go with it (IPv4 and IPv6)- e.g. OPT3_VPNV4 and OPT3_VPNV6. Then you can put the gateway into gateway groups, add policy routing rules that feed packets into the gateway or gateway group…
The interface assigned to the OpenVPN server should have IPv4 Configuration Type none and IPv6 Configuration Type none to get these "virtual gateways" to appear.
When I add an ordinary "allow all" firewall rule to OPT3, I get:Jan 25 19:27:18 php: : Could not find IPv4 gateway for interface (opt3).In /etc/inc/filter.inc at line 2097, it now decides interface_has_gateway, because these "virtual gateways" are being created for the OpenVPN server now. Then it tries to get_interface_gateway - but that does not return an IP address, because in this case the gateway does not have a "real" IP address defined. Instead of putting a "reply-to" clause in the rule, it spits out the error message.
But it looks like the rule wil still be created without the "reply-to" option, and previously the "reply-to" was not put in for this case. So I can't easily see how this actually breaks any previous routing.
It would be interesting to know what rules you have on your OPTn OpenVPN assigned interface - I guess that one or more of those rules is implemented differently now. -
That commit wouldn't have changed anything for clients though. It only added functionality, it didn't alter or take away what was already there and working.
-
The error message comes on the server end - at the OpenVPN server which has an interface assigned on his "one-armed router". It is a new code-path, because now the OpenVPN server assigned interface gets "virtual gateways" created, where it did not before.
-
Right, but that wouldn't have broken anything, routing-wise.
-
Yes, I agree, I can't see how the code-path that generates this error message actually makes any difference to the final rule set that is generated. So, now I wonder what the actual problem is? Is there some other influence of having the "virtual gateways" exist now on the OpenVPN server end? What other code paths might be taken now that have an unexpected side-effect.
@flyingtino - do you have other "interesting" rules on that OpenVPN assigned interface, or routing stuff to that interface or whatever, that might give clues about how your routing could be changing when you upgrade? -
Thank you Jimp and Phil for the replies.
In both the environment there a no special rules or routing lines. Just a plain vanilla gateway, with a openvpn server virtual opt interfaces and one real wan interface, but not passing any traffic…
Therefore I was triggered by the error message.I'm happy to mail you the ipadres of this testserver to have a peek.
Regards, Martin
