Can only get internet on one interface, and I don't know why the others dont have access
-
pfSense CE 2.7.2-RELEASE (amd64).
My pfSense box is in DMZ behind another router, and one of the interfaces behind pfsense works just fine. But not all of them, and I have no idea why.My SERVER network
This one has access to internet and all other networks works just fine:
My KLIENT network
I manage to ping IP-addresses outside the network (internet) with this, but am not able to ping domains like vg.no.
My GJEST network
I manage to ping other networks internal, but no internet access
Anyone see the issue?
Goal:
GJEST: Only access to internet,
KLIENT: Access to all networks and internet -
@Flemmingss said in Can only get internet on one interface, and I don't know why the others dont have access:
My KLIENT network
I manage to ping IP-addresses outside the network (internet) with this, but am not able to ping domains like vg.no.Seems to be a DNS issue.
What is you DNS server? If pfSense, how did you set it up?My GJEST network
I manage to ping other networks internal, but no internet accessThis rule allow access to WAN subnets only. WAN subnets are the subnets defined on the WAN interface. It's not the whole internet.
To allow internet access, you have to select any for the destination.
You can block access to local subnets with an additional block rule on the top of the rule set. -
@viragomann
Thanks, I got my guest network to work that way.
Now I just has to block the other networks.When it comes to DNS, this is my settings:
10.0.1.1_services_unbound_advanced.php.png
10.0.1.1_services_unbound.php.png -
@Flemmingss said in Can only get internet on one interface, and I don't know why the others dont have access:
When it comes to DNS, this is my settings:
10.0.1.1_services_unbound_advanced.php.png
10.0.1.1_services_unbound.php.pngWell, that pretty default and I'd expect it to work. But does the device on KLIENT subnet use pfSense for DNS resolution?
To investigate set the Resolver log level on the advanced tab to 3 and run an "nslookup google.com" on the device. What is the output and what to you see in the DNS log then.
BTW: I saw that you have a allow-any but RFC 1918 rule on the GUEST network. Yeah, this rule should allow access to the internet, but you also need a rule for allowing DNS access to pfSense above of it. NTP is also recommended.
I have forward DNS and NTP to the LAN address, so here is the destination "LAN address", but you can also use "This firewall".
Then you can remove the allow-any rule. -
@viragomann
Thanks, I got my GJEST network to work the way I wanted yesterday, I found out about the DNS thing there. Are "This Firewall" equivalent to "GJEST address" as you describe? If that case I think that will be a better way to do it.
Also, I only block the 24-block because I am using just 10.0.x.x in my network, and are behind a 192.168.x.x. NAT (Maybe this doesn't really matter? As the range is on the other side of the firewall)I had some issues yesterday because I got access to other LAN's with this setup, but after some diagnostics I found out I had Tailscale (connected to pfSense) running on the laptop, when I disabled it on the test-computer the rules worked perfect.
When it comes to KLIENT and the DNS issues, I will try the actions you recommend and see how that works. I thing I can do it this evening and will update this thread.
(EDIT: Added NTP to the GJEST)
-
@Flemmingss said in Can only get internet on one interface, and I don't know why the others dont have access:
Are "This Firewall" equivalent to "GJEST address" as you describe?
No, it's not the same. The alias "This firewall" includes all IPs which are assigned to pfSense; any interface and as well localhost (127.0.0.1).
So if your DNS Resolver is listening on all interface it is as save as using the interface address, but more flexible.Also, I only block the 24-block because I am using just 10.0.x.x in my network, and are behind a 192.168.x.x. NAT (Maybe this doesn't really matter? As the range is on the other side of the firewall)
If you include the 192.168/16 range into the alias, the rule will not allow access to it of course, e.g. to the web interface of the router in front of pfSense.
-
Your SERVER network firewall rule look fine to me.
Your KLIENT network firewall rules loo, fine to me.
Your GJEST network firewall .... you need to explain here something to me.
Lets start with an easy question : what do you think what will happen when you set up a pass rule that is limited to "WAN subnets" ?Also : none of the traffic that neters into the GJEST interface matches any rules listed. So the default (hidden !) rule will match ; block everything.
I can see that the rues don't apply : all the counter states are 0/0.@Flemmingss said in Can only get internet on one interface, and I don't know why the others dont have access:
I manage to ping IP-addresses outside the network (internet) with this, but am not able to ping domains like vg.no.
ping 8.8.8.8can go to work right away, it has everything it needs : an IP address.
ping vg.nooften doesn't work, as ping needs to do something first : it needs to resolve the host name vg.no to an IP address.
The question is : the device you use, where does it go when it needs to resolve something ?
YIf this device is a windows device, typeipconfig /alland you can see it :
Serveurs DNS. . . . . . . . . . . . . : 2a01:cb19:907:dead:beef:77ff:fe29:392c 192.168.1.1Important info : both of these IPs are the interface IPs of my pfSense LAN
And who is listening on these two IPs (on port 53, TCP and UDP)? The resolver of pfSense !
On the pfSense side of things : is the pfSense resolver actually listing on my (all my !!) LAN interfaces ?
Let's check :
=> yes it is.
You can also use
nslookup gv.noas this is the right tool to analyze DNS issues.
-
@viragomann
Thanks, in that case I can include 192.168/16 also, tested and works.
I am very sure I have the guest network ok, this is the setup, and it works how I think it should:
@Gertjan As you se above, I think my guest is ok. But thanks for a very god post and explanation, however, I still got some issues with the KLIENT network.
As you can see in my first post in this thread, it has the exact same fw rules as SERVER, it just has the Anti-Lookout rule also. So I can't see how it don't behave like it.I have done nslookup on the KLIENT network, and I am getting ***UnKnown can't find vg.no: Query refused.
I tried to change the DNS server on the computer when it was connected to KLIENT to the same as other networks (as it has access to other LANs), here is the test results:
10.0.1.1 (LAN DNS): ok
10.0.21.1 (KLIENT DNS): ***UnKnown can't find vg.no: Query refused
10.0.24.1 (SERVER DNS): ok
10.0.23.1 (KLIENT DNS): ***UnKnown can't find vg.no: Query refusedBut, even if I can do nslookup using the 10.0.1.1. dns for example, if I ping it I got "Ping request could not find host vg.no"
But I can ping both ip-addresses I got from the nslookup command.
I tried to add some more rules to the KLIEN network, so it looks like this now, it works the same, still problems reaching internet og ping internet.
-
I did a little more testing, checked every setting in the pfsense UI, did not found any thing that I think looks wrong.
So i removed the KLIENT interface and the VLAN for it (21) and recreated it, it did not help, same issue.However, I found one interesting thing.
I added the blocked DNS trough system logs and created an EasyRule,.
10.0.21.134 is my test client.
How is this working, and not my own DNS rule?
-
@Flemmingss said in Can only get internet on one interface, and I don't know why the others dont have access:
How is this working, and not my own DNS rule?
In your image, neither of those rules have matched anything...note the 0/0 in the States column.
Your third rule allows from KLIENT subnet to GJEST address, is that a configured DNS server for devices on KLIENT? I would expect they use KLIENT address for DNS.
-
@SteveITS You are right :P Looks like i forgot to change the destination when i copied that rule.
Corrected, tested a little, and it looks like this is working fine! Thanks.
Looks like my issues are solved, but I will look more tomorrow.
