New to pfSense
-
I have a rather major problem that has only now been brought to my attention via the System Logs. Today, the firewall was reporting many requests on the WAN interface. At the time, I had no idea what the IP address was until I looked further. Turns out, my pfSense gui is available to connect on both my LAN address (10.10.10.10) as well as an address on the WAN DHCP Gateway (100.xx.xx.xx).
I have reconfigured the System settings and changed the port for https, disabled both the webConfigurator anti-lockout rule and Webgui redirect rule (I have created firewall rules to enable me to do this).
There is a VPN connection via OpenVPN however I have disabled all the settings and restarted pfSense and still I am able to access the webgui via the WAN DHCP Gateway address (100.xx.xx.xx).
I have not added any rules to the WAN firewall rules.
I must have overlooked a setting somewhere but cannot find it. Does any one know where else I can look to close this loop hole?
Edit: doing more research it seems the webgui listens on all interfaces. Is there a way to disable this? When I try and access the webgui via my phone on 4G/LTE it is blocked. How did these other external ip’s manage to find my webgui address on the WAN interface?
-
The default rules on the lan would yes allow you to access the gui on the wan address from the lan.. Since the default rules on the lan are any any.
If you want to block lan side access to your webgui on your wan IP, then you would need to specifically block this access.. This is where the "this firewall" built in alias comes in handy.
It will include ALL ips of the firewall..
-
@Sir_SSV said in New to pfSense:
Turns out, my pfSense gui is available to connect on both my LAN address (10.10.10.10) as well as an address on the WAN DHCP Gateway (100.xx.xx.xx).
This is entirely normal. Any interface address on pfSense is reachable from the LAN, unless specifically blocked. Try from elsewhere and see what happens. I bet you can't get in.
-
Yes you are correct. I made the mistake of checking the webgui via WAN ip on LAN and this did give me a shock!
How would these external IP’s have found the WAN IP address of the webgui when I didn’t even know what it was?
It would be good if in a future pfSense release they gave us the option of choosing which interface the webgui listens on. I would have thought it would be preferable to have the webgui invisible on the WAN side
-
@Sir_SSV said in New to pfSense:
How did these other external ip’s manage to find my webgui address on the WAN interface?
When I try and access the webgui via my phone on 4G/LTE it is blockedSo what are these "external" ips that are accessing your gui? And how are you showing they are accessing your gui? A login attempt in the logs? Or your firewall listing a block?
-
When I tried via my phone on 4G/LTE I couldn’t even reach the webgui. Was shocked when I saw the logs and I tested the IP address seeing it was my webgui that opened!
-
Firewall was listing a block.
It listed as the interface being WAN, “from” being overseas IP (they came from America, Italy, Dubai and that was the ones that it could resolve. Used Shodan.io to resolve the others) and “to” being the WAN webgui address however on different ports (I have changed the https port from 443 to a much higher one)
-
@Sir_SSV said in New to pfSense:
When I tried via my phone on 4G/LTE I couldn’t even reach the webgui. Was shocked when I saw the logs and I tested the IP address seeing it was my webgui that opened!
So, it's performing as expected. As pfSense is a router, you can access any address on it. However, the firewall rules are applied to an interface, which is why you can get in from the LAN, where there are no rules blocking access, but can't from outside, as the rules are on the WAN interface. As I said, this is entirely normal.
The log entries show the firewall is doing it's job, when someone tried to get in from elsewhere. Your cell phone attempts should have also appeared in the log.
-
@Sir_SSV said in New to pfSense:
Firewall was listing a block.
Well yeah there is a shitton of noise on the net.. Your firewall logging the noise is the default (log default blocks).. If you don't want to see the noise, turn off logging default block rule.
80/443/22/23/1433/3389 are going to see lots of noise..
-
I've managed to get Internet from a VLAN port on SG-3100. The speed on it however is much slower than that of from ISP. What can I do to get the speed the SG-3100 offers?
-
I have only recently set up DNS Resolver (prior to this I was using my ISP's DNS servers).
On one of my vlans is my FreeNAS server that has no access to the internet however I have made rules for it to be made available to the intranet as well as allowing DNS (via my ISP DNS on port 53) and Gmail (on port 587).
Is there a way to change the DNS rule to use the DNS Resolver? I tried changing the Destination to 127.0.0.1 however my test emails on my FreeNAS server failed.
Firewall rule is:
Protocol - IPv4 TCP/UDP
Source - FreeNAS address
Destination - 127.0.0.1
Port - 53 (DNS) -
@Thuan said in New to pfSense:
The speed on it however is much slower than that of from ISP.
And what speed is that?
-
@Sir_SSV said in New to pfSense:
I tried changing the Destination to 127.0.0.1
huh? When would your client send anything to pfsense if the destination was loopback?
-
@johnpoz said in New to pfSense:
@Sir_SSV said in New to pfSense:
I tried changing the Destination to 127.0.0.1
huh? When would your client send anything to pfsense if the destination was loopback?
I have no idea! Just not sure what address to place in the destination so FreeNAS can use the DNS Resolver. With my FreeNAS system it sends regular updates to my Gmail notifying me of system status
-
That would be the address its listening on, your lan address, or vlan address, optX address, etc.
You then set your freenas to use pfsense as its dns.. Or just hand it out via dhcp - which is default.
-
@johnpoz said in New to pfSense:
That would be the address its listening on, your lan address, or vlan address, optX address, etc.
You then set your freenas to use pfsense as its dns.. Or just hand it out via dhcp - which is default.
I do have dhcp set up for the vlan, and the dns settings I left blank.
Should I fill the dns as the pfSense ip?
-
if you left it black - it would hand out the address of that interface.. Which is what it states right there on the box!
-
@johnpoz said in New to pfSense:
if you left it black - it would hand out the address of that interface.. Which is what it states right there on the box!
I might do a restart of the FreeNAS server and see how I go. Will also delete the firewall rule for DNS
-
What firewall rules do you have on this interface - and can you not just look direct on the freenas to validate where it pointing to for dns.. And do a query on it directly to validate its dns is working..
Was your gmail working before - I know there is something coming/here with the gmail APIs that there was/is an update for my synology nas that uses gmail for notifications because of the update in the API and if you didn't update your notifications would fail.
Version: 6.2.2-24922-2
(2019-07-04)
In response to Gmail API changes, your DSM needs an update to this version to continue the functionality of sending notifications via Gmail. If you wish to skip this update, or if your Synology product model is not eligible to update to DSM 6.2, please refer to the following article which will guide you through the manual configuration: How to use Gmail SMTP server to send emails for DSMI would assume this could/would effect anyone use gmail APIs to send mail, etc.
-
@johnpoz said in New to pfSense:
What firewall rules do you have on this interface - and can you not just look direct on the freenas to validate where it pointing to for dns.. And do a query on it directly to validate its dns is working..
Was your gmail working before - I know there is something coming/here with the gmail APIs that there was/is an update for my synology nas that uses gmail for notifications because of the update in the API and if you didn't update your notifications would fail.
Version: 6.2.2-24922-2
(2019-07-04)
In response to Gmail API changes, your DSM needs an update to this version to continue the functionality of sending notifications via Gmail. If you wish to skip this update, or if your Synology product model is not eligible to update to DSM 6.2, please refer to the following article which will guide you through the manual configuration: How to use Gmail SMTP server to send emails for DSMI would assume this could/would effect anyone use gmail APIs to send mail, etc.
Under the static mapping for the FreeNAS vlan I had my ISP’s DNS. Removed these, deleted the firewall rule for DNS and restarted the FreeNAS server and all is working.
Emails now being sent using DNS Resolver
Big thanks for all your help @johnpoz
