Php: : Could not find IPv4 gateway for interface (opt1).
-
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
