Ignore any IP not resolving to a trusted domaine
-
@johnpoz Ok, will look into this.
Just to be clear as I am doing these changes over my Open VPN connection (not onsite now). I don't want to be locked out and have to drive to office! ;)
- I define these dyndns fqdn Aliases as HOSTS right? like in my original screenshot.
- And in my WAN rule (which comes from the OpenVPN VPN wizard), I replace the SOURCE to Alias with my alias as you did
- as for the Destination I leave it like this?
Thanks!
-
@wastapi well to make sure you don't lock yourself out... You could always create a rule that allows your current IP to the gui directly from the IP... That way you would be able to get in, even if you mess up your vpn access, etc.
I always put in some sort of out of band access when doing anything that could lock me out ;)
Also good check is put that alias into some dummy rule, so it gets evaluated. Alias do not get resolved unless in a rule.. And then check your tables under diagnostic to make sure the IPs are in there for those fqdn..
example
-
@johnpoz
mmm. Right. not sure how this rule should be performed though.
Sorry for the Newbe stuff.
:/ -
@wastapi what rule a gui access rule? Just allow on your wan to wan address on port your gui is running on, and then the IP your currently coming from as source..
Validate that works before you mess with your vpn rule.
-
@johnpoz
Sure! But then how will I test that my new alias setup is working as I now have a rule that allows my IP through anyway? -
@wastapi -- look in the table to make sure its showing the IPs, etc.
Your other rule is for vpn, not direct access to the web gui via the wan IP.. Completely different modes of connecting..
-
@johnpoz Yes, but as I am on the same IP, the VPN still works. So even disabling the Open VPN rule does allow me to connect as the IP is allowed 100%.
So I guess I should limit the ports on the new temporary rule to JUST allow the 80 port for the GUI? Or other ports too?
Thanks!
-
@wastapi huh?? Create your web gui port rule and access it.. via your public IP, you wouldn't be going down the vpn to get ot your pfsense wan IP..
-
@johnpoz Ok so I should understand from your last reply that the temporary IP assigned "Web GUI rule" should not be on all ports (.) but only 443?
-
@wastapi is your web gui using 443, then yeah.. Mine uses 8443 for example..
-
WOHOOOO!!! It works! :) :)
Thanks a lot @johnpoz ! -
@johnpoz
I have an issue. It seems that ANY IP can connect to the open VPN now, even if they are NOT in the alias pool.I have put the said rule on my WAN interface.
Should I also put it on my openvpn interface?I would have expected my WAN to simply block it if not in the alias pool, and for the traffic NOT to reach the open VPN because of that.
Thanks for your continued help.
-
@wastapi without seeing your rules I really can not even guess to what could be going on.
But you can validate what is in the alias via the diagnostic / table menu. For something to talk to your openvpn service listening on your wan IP.. You would need a rule on your wan to allow it. The rules in your openvpn interface would be for what traffic is allowed via that interface - not for connecting to it from wan.
-
Thanks for pointing diagnostic / table menu
1-Well we have another issue then:
It seems that an IP was added in the table although it has absolutely NO link to ANY domain in my Alias configuration. Any clue?2-And here is my rule on my WAN interface
3-And here is my rule on my OpenVPN (Which is not an interface)
-
@wastapi that is not your rules that is 1 rule - without knowing what rules above that, or in floating its just a guess if that rule is the one that will be trigged.
Lets see your wan rules..
example..
And do you have rules in floating - if so lets see them.. Also what do you have set for your port forward "Filter rule association"
If you have that set to PASS vs an association with your wan rule - you could be allowing anything in, etc.
-
- l only have ONE allow rule on my WAN. The one I sent.
- I only have ONE allow rule on my OpenVPN. The one I sent.
- I have a few rules on my Bridge interface, but this should not be related. Also none refer to this Alias setup.
No floating rules are currently defined
Nothing found about port forward "Filter rule association"On my WAN I have the standard "Block bogon networks" & "Block private networks" blocking rules at the top.
-
@wastapi said in Ignore any IP not resolving to a trusted domaine:
Nothing found about port forward "Filter rule association"
Ah my bad this openvpn running, not a port forward - you can ignore that..
Well how exactly are you saying anything can connect are you logging that rule that allows your openvpn, are you seeing connection attempts in the vpn log?
-
@johnpoz
An employee with a wan IP not resolving to any known alias is ABLE to connect to our VPN.
And I see his IP in the diagnostic / table for my alias.First, I don't understand how come his IP is listed there! There is absolutely no relation between his remote WAN IP to any of my alias.
Hence I would have expected my rule to ignore any WAN connection if it is not in the Alias set.
-
@wastapi said in Ignore any IP not resolving to a trusted domaine:
First, I don't understand how come his IP is listed there
Well if its in your alias table - then yes it would be allowed..
-
@johnpoz
Hehe... Yes I understand why it allowed the traffic is because the IP is listed in the Alias table. ;) But I don't understand HOW this IP got listed there. ;) In any case I have emptied the table.It seems the Alias table is really slow to update/refresh.
If I empty it, it will not allow me through anymore. Although the FQDN does point to the right IP in the remote DNS. (tested by nslookup)I have changed Aliases Hostnames Resolve Interval to 10 seconds. Same problem - it does not update after 10 seconds. Alias table remain empty.
The only way I get this working is by saving my alias setup and applying multiple times (3). unusable.
