Cannot save Interface settings (PPPoE Password and confirmed password must match)
-
Hardware: Netgate SG-1100
When trying to save settings for a new interface for a VPN tunnel i get the following error:
The following input errors were detected:
PPPoE Password and confirmed password must match!There is no settings for this.. Is there a quick workaround for this error?
-
https://forum.netgate.com/topic/140917/interface-assignment-error-openvpn-or-gree-interface-type next time don't be lazy and use the search page yourself.
-
I did search for a solution but only found another thread that did not work for me, i used google search though since normal forum search engines normally suck.
I googled a long time for the error so you cannot blame me for being lazy
Infact it might have been the auto logon feature that somehow interfeared with it.. Strange.. And very strange error message? How come it complain about PPPoE when there is no configuration for it?
-
Have you ever configured a PPPoE connection there? Or any PPP?
I suspect it may have some setting remaining in the config against OPT1. Try looking in the config file directly in /conf/config.xml at the OPT1 settings.
But yeah it could also be your browser auto filling a form field that is usually hidden unless you select PPPoE as the connection type.
Steve
-
@stephenw10
No I have never ever used or configured a PPPoE connection :)Yes, no idea to put more effort into this. I guess it was the auto fill feature. I have turned it off now to be sure. It wanted to fill the MAC address field with my login name i noticed but i always removed it before i saved the settings. But maybe it filled some hidden field as you said.
Here is what the config.xml say about my OPT1 interface
<opt1>
<descr><![CDATA[VPN]]></descr>
<if>ovpnc3</if>
<blockpriv></blockpriv>
<blockbogons></blockbogons>
<spoofmac></spoofmac>
<enable></enable>
</opt1> -
That looks fine. Looks like it was a browser autofill issue.
I've been caught out by that from the LastPass browser plugin before.
Steve
-
@stephenw10 Ok. Thanks for the help! :) I have learned something new :)
Now i have to try to fix my VPN port forward that goes back out over my WAN link instead. Reading pfsense documentations and threads about the issue for 2 days now :)
-
I don't see a thread about that but I'd guess it's because you either don't have the OpenVPN interface assigned or you do but have pass rules on the main OpenVPN tab rather than the new interface tab. You need to pass the traffic on the assigned interface to get the required 'reply-to' tag on the rule. Otherwise replies will use the default system route.
Steve
-
@stephenw10
I have not created a thread about it since there is so many already. But none match my issue so i think i will. I must have missed something.. but i have gone over it so many times now..I have a interface assigned (OPT1 renamed to VPN). I had a pass rule there and when i did a port forward it seems to add the rules in there also..
-
Be sure there are no rules that will pass it on the OpenVPN tab as they are applied first and will not add the reply-to tag.
Also make sure to clear any open states between tests as it may not be using the new rules otherwise.
Steve
-
@stephenw10
Ahh! Open states! That one i did forgot! Thanks! will test otherwise i will create a thread about it.
OpenVPN tab is used for another VPN tunnel though. On that one i have specified 2 remote (internal) networks that traffic will be routed too. That one has a "allow all" rule also. -
Yeah, you can't have an 'allow all' style open rule on the OpenVPN tab. If you have unassigned other OpenVPN instances just make sure to specify source subnets there so it doen't match traffic that needs to be passed on the assigned interface tab.
Steve
-
Ohhh.. i had to read your comment several times to understand it.. So if i have 2 OpenVPN tunnels the openvpn tab will match traffic for both tunnels even if one openvpn tunnel is assigned to an interface (VPN)?
I also noticed i had a allow all on the VPN tab, and removed that now.
So i have 2 OpenVPN tunnels.
1 tunnel goes to a LAB environment at my work (Network there is 10.52.0.0 and 10.51.0.0)
1 tunnel goes to "internet" via a VPN provider.. This tunnel is assigned an interface called VPN.Are you saying the "internet" VPN tunnel will also use rules on the "OpenVPN" tab even if i assigned it an interface (VPN) ?
My OpenVPN tunnel to the LAB has this settings:
-
@Taz79 said in Cannot save Interface settings (PPPoE Password and confirmed password must match):
Are you saying the "internet" VPN tunnel will also use rules on the "OpenVPN" tab even if i assigned it an interface (VPN) ?
https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/openvpn-traffic-filtering.html
-
@Grimson
ohhhhhhhh :)I like how you instead of typing an answer paste links ;) I will try it by removing all the rules in the OpenVPN tab..
-
@Taz79 said in Cannot save Interface settings (PPPoE Password and confirmed password must match):
I like how you instead of typing an answer paste links ;)
Why should I write things again that are already written in the documentation. That would be wasted time.
-
WOHO! It's working now! ..
So what was happening if i understand this correctly was that incoming traffic from my "internet" VPN was matched by the OpenVPN rule.. So the forwarded port from my internet VPN, where does that get sent if it encounter an "allow all" rule? Since its coming from the internet it would not know where to go?@stephenw10 where do i send the beer keg? :D Give me your BTC address :) :)
I have been over the rules, port forwards and LAN rules over and over and could for my life not understand how it could not work... lol ... -
@Grimson must thank you also for the link ;)
-
Yes, rules on the OpenVPN tab get applied to all incoming traffic coming over OpenVPN and they get applied before and specific rules for assigned OpenVPN interfaces. The behaviour is the same as interface groups and the interfaces in those groups but most people never use interface groups so never hit that.
Traffic coming on on the port forward was hitting the allow all rule on the OpenVPN tab and would have been correctly forwarded to the target. But because it does not get tagged 'reply-to' the replies from the target just go back out the system default route, usually the WAN, so the connection fails.
Steve
-
@stephenw10
Ok and that was exactly what i observed :) Thanks again!
