(SOLVED) Problem with client connect through static IP cable internet
-
@paprikawuerzung said in Problem with client connect through static IP cable internet:
Is this something specific to my static IP setup on WAN? Because when I use a PPPoE WAN configuration I do not need to open the ports manually - there, the configurations are done automatically and without problems at all!
pfSense has a default rule on LAN, allowing ANY traffic outbound to the internet. If you have that one still in place your problem is not layer 4/rules related. Your NAT is configured on automatic? How about showing the rules and outbound NAT settings as well as the WAN interface settings?
-
Thanks again for your answers!
@JeGr said in Problem with client connect through static IP cable internet:
@paprikawuerzung said in Problem with client connect through static IP cable internet:
Is this something specific to my static IP setup on WAN? Because when I use a PPPoE WAN configuration I do not need to open the ports manually - there, the configurations are done automatically and without problems at all!
pfSense has a default rule on LAN, allowing ANY traffic outbound to the internet. If you have that one still in place your problem is not layer 4/rules related. Your NAT is configured on automatic?
Yes, I have all defaults configurations in the Firewall/(outbound) NAT sections.
How about showing the rules and outbound NAT settings as well as the WAN interface settings?
I am currently not on-premise. I will provide all screenshots later on. But as I said before: they are pretty standard!
-
No problem. If there're indeed the defaults at work we'll have to check from the client up to the WAN to find the culprit here. That's why screens of WAN IF config, NAT outbound, firewall rules WAN/LAN and DNS resolver (unbound) config may be necessary. :)
-
but when he wrote that "nslookup google.de 1.1.1.1" is not working that can only be because port 53 is closed somehow/somewhere,that's why i suggested to check firewall logs
anyway
we will wait for the screenshots -
What kind of configuration are you using on DNS? Is it Resolver or Forward?
If on a local machine youdig google.dewithout any other options, which server do you query?Viewing on your local machine, what DHCP DNS config is being passed to clients?
-
@kiokoman said in Problem with client connect through static IP cable internet:
but when he wrote that "nslookup google.de 1.1.1.1" is not working that can only be because port 53 is closed somehow/somewhere,that's why i suggested to check firewall logs
Nope, could also be a problem with unbound/dnsmasq (depending on wheter he uses forwarder or resolver) and how it is set up and configured. That's why I was asking about what DHCP settings are configured in another thread. If he pushes an external non-working DNS to the client, that would explain the broken setup. @maverickws question points into the same area :)
Greets
-
Wow, a lot of answers!
@JeGr said in Problem with client connect through static IP cable internet:
@kiokoman said in Problem with client connect through static IP cable internet:
but when he wrote that "nslookup google.de 1.1.1.1" is not working that can only be because port 53 is closed somehow/somewhere,that's why i suggested to check firewall logs
Nope, could also be a problem with unbound/dnsmasq (depending on wheter he uses forwarder or resolver) and how it is set up and configured. That's why I was asking about what DHCP settings are configured in another thread. If he pushes an external non-working DNS to the client, that would explain the broken setup. @maverickws question points into the same area :)
Greets
The DNS provided by DHCP to the client does not seem to be the problem! The client has 192.168.178.1 (pfSense) as DNS and pfSense in turn uses the DNS Forwarder (unbound) to resolve the domains (which works just fine).
The problem is: the clients are not able to make DNS queries themselves (= directly to 8.8.8.8 for example)! The gateway (192.168.178.1 - pfSense) is set correctly on the clients. But all connections with ports (layer 4) time out...
I strongly believe that this is a gateway/NAT/firewall problem - not a DHCP config problem at all. pfSense gets all the traffic from the clients - but somehow does not handle it correctly.
I will create a complete fresh install of pfSense, do minimal configuration (so that pfSense hat an internet connection through the cable) and will send screenshots in 3-4 hours!
-
@paprikawuerzung
Hi there,I don't think you have the correct configuration, and may I add I did this mistake recently of having forwarder mode enabled thus bypassing unbound.
btw, is 192.168.178.1 the pfSense?If you go to Diagnostics > DNS Lookup you can resolve properly from the pfSense?
Basically if you are using DNS Resolver (unbound) you don't need to set any DNS servers (much less Google's, phew, try CloudFlare or OpenDNS), but anyway with this configuration you may set NONE.
The purpose of DNS Resolver is to query the ROOT DNS servers on the top of hierarchy.
For this you must disable the "enable forwarding mode" on DNS Resolver.The DHCP will then pass the pfSense itself as DNS for your clients.
You can make queries via IP, but you cannot resolve IP's from names. That's DNS.
-
@maverickws said in Problem with client connect through static IP cable internet:
@paprikawuerzung
Hi there,I don't think you have the correct configuration, and may I add I did this mistake recently of having forwarder mode enabled thus bypassing unbound.
btw, is 192.168.178.1 the pfSense?If you go to Diagnostics > DNS Lookup you can resolve properly from the pfSense?
Yes, I can query everything without any problem. I am really, really, really sure that DNS is not the problem since HTTP and SSH (with some IP address) do not work (which does not have anything to do with name translation at all) on client side - but work without problems on pfSense (see diagram)...
Basically if you are using DNS Resolver (unbound) you don't need to set any DNS servers (much less Google's, phew, try CloudFlare or OpenDNS), but anyway with this configuration you may set NONE.
I have 1.1.1.1 and 8.8.8.8 set in the general setup - they are used by unbound as far as I know. But as I said before: I do not think DNS is the problem - HTTP, SSH, ... all do not work from the client - but using "Diagnostics -> Command Prompt" on pfSense they work without problems.
The purpose of DNS Resolver is to query the ROOT DNS servers on the top of hierarchy.
For this you must disable the "enable forwarding mode" on DNS Resolver.The DHCP will then pass the pfSense itself as DNS for your clients.
You can make queries via IP, but you cannot resolve IP's from names. That's DNS.
I know what DNS is for and I also understand that there might be a problem with it - but also IP-based traffic (without domain names at all) do not work also - they all time out.
-
When you say "HTTP, SSH all do not work from the client" in the example (diagram) you provided you have:
curl google.de not working - still requires DNS to resolve google.de - sorry I didn't get from your previous posts that you were lacking connectivity when using IP addresses.
I'm not about nslookup so I'll skip that one in particular.
Anyway cause I gtg I'll leave my DNS Resolver config so you can compare to yours:
Also, if you do a
curl 216.58.211.35what is the output?Do you have the default allow LAN to any rule on your firewall?
Firewall > Rules > LAN
- Action: Pass
- Interface: LAN
- Address Family: IPv4
- Protocol: Any
- Source: LAN Net
- Destination: any
-
Thanks for your answers again!
@maverickws said in Problem with client connect through static IP cable internet:
When you say "HTTP, SSH all do not work from the client" in the example (diagram) you provided you have:
curl google.de not working - still requires DNS to resolve google.de - sorry I didn't get from your previous posts that you were lacking connectivity when using IP addresses.
Yes,
nslookup google.deis working (eg. returns 172.217.21.227) on the client - so doingcurl google.deor doingcurl 172.217.21.227results in the same behavior.
Doingnslookup google.de 1.1.1.1(ie. using Cloudflare 1.1.1.1 as the DNS server) on the client does not work. Same behaviour as with HTTP, SSH, ...I'm not about nslookup so I'll skip that one in particular.
Anyway cause I gtg I'll leave my DNS Resolver config so you can compare to yours:
Also, if you do a
curl 216.58.211.35what is the output?Time-out on the client. Same with SSH. Works fine on pfSense (
Diagnostics -> Command Prompt).Do you have the default allow LAN to any rule on your firewall?
Firewall > Rules > LAN
- Action: Pass
- Interface: LAN
- Address Family: IPv4
- Protocol: Any
- Source: LAN Net
- Destination: any
I will have to look later - but the config is the default and I think it is there.
I am really unsure what pfSense is doing with client traffic! Normally, I would assume it does outbound NAT (= gives traffic outside some temporary ports and writes its own (external) IP address in the SRC field) and does the translation backwards when the requests come back. But somehow in this chain, the packets get dropped... Is there a possibility to track all traffic (= testing NAT)?
-
I found the solution: I had to add a firewall rule to allow OUT traffic from LAN -> WAN. Floating Rule...
I am not entirely sure why this was necessary but I wanted to rule out any firewall involvement. All the traffic from the LAN net to the WAN net was silently blocked by pfSense.As I am not that familiar with firewall rules: is this a potential security risk?
-
Post a screencap of your LAN rules so we're not guessing what you've got going on. You should NOT need floating rules unless you're doing traffic shaping or a complex config. By default, LAN allows all traffic to anywhere.
-
I currently do not have access to pfSense - I will post the screenshots tomorrow morning!
Apart from that: thousand thanks for your help and time :)
-
This post is deleted! -
This is my working config: config-pfSense.SCRUBBED.xml
-
Nobody wants to parse through an XML file. Screencaps are much better, a picture worth a thousand words etc.
-
@KOM said in Problem with client connect through static IP cable internet:
Nobody wants to parse through an XML file. Screencaps are much better, a picture worth a thousand words etc.
I am sorry but I am not on-premise. I only have the config here. But I'll try to create a VM, import the config and make screencaptures.
-
-
Get rid of that floating rule. You don't need it and it may be part of the problem. If you lose connectivity after deleting that rule then there is a deeper problem to be discovered and fixed because, like I said earlier, floating rules are used for QoS and special custom configs. You don't need any floating rules to get basic connectivity working.
Your LAN rules look good but there is no traffic logged (0/0 B for each rule) which means pfSense isn't seeing anything from LAN that is hitting those rules. The floating rule may be taking precedence.
What specific errors are the clients getting when trying to connect using various things like ssh or http/s? The exact error text can be very helpful.
