PfSense NAT does not seem to work
-
Hello all,
I have installed a fresh copy of pfSense on my HP server running XenServer 6.5
For now, I have the server behind my (Ziggo) modem which is also NATing (modem still NATing for testing purposes).
I have a Win2k12 R2 VM which is the Domain Controller and DNS server.pfSense is set-up as default GW and is a DHCP server, where he is passing the 2k12 server ( 192.168.60.10 ) as DNS server.
The pfSense VM WAN IP is added in the Ziggo modem for DMZ, so all ports are being forwarded to it's WAN IP.
Using NAT I am forwarding RDP port to the 2k12 server.
Using Squid3 I want to be able to "content switch" URLs, eg: sub1.domain.com goes to webserver1 and sub2.domain.com goes to webserver2.None of the above rules are working (yes I also added the rules to the firewall).
When I RDP to my external IP, nothing happens.
When I RDP to the pfSense WAN IP ( 192.168.178.28 ), nothing happens.
When I RDP to the Win2k12 server IP ( 192.168.60.10 ), RDP is successful.Same is for port 80 traffic.
Also, all the PCs in the 60.x network are not able to do DNS lookups but ping to external IPs (eg 8.8.4.4) is working.
On the 2k12 server I have DNS forwarders set-up, but they are timing out (see attachments).2 different problems, but what could be wrong here?
Edit:
In the NAT rule for RDP I enabled NAT reflection (NAT + proxy) and now RDP to the pfSense WAN IP ( 192.168.178.28 ) is working, but RDP from the outside network to my external IP is still not working.
Also Squid3 redirects/forwards is still not working.
![DNS lookup.PNG](/public/imported_attachments/1/DNS lookup.PNG)
![DNS lookup.PNG_thumb](/public/imported_attachments/1/DNS lookup.PNG_thumb) -
A couple of notes:
Double-NATing for 'testing purposes' is completely broken idea. What are you testing there? Completely different thing than the one that's eventually going to be used? How's that useful?
You shouldn't use pfSense as DHCP server in AD environment.
Leave Squid totally out of the equation until you have basic things working!
Without posting your port forward/firewall rules screenshots, you might as well try a crystal ball.
There are firewall logs available, use them. -
A couple of notes:
Double-NATing for 'testing purposes' is completely broken idea. What are you testing there? Completely different thing than the one that's eventually going to be used? How's that useful?
You shouldn't use pfSense as DHCP server in AD environment.
Leave Squid totally out of the equation until you have basic things working!
Without posting your port forward/firewall rules screenshots, you might as well try a crystal ball.
There are firewall logs available, use them.Thanks for your reply.
This morning I called my ISP and my modem is now in bridge mode, so pfSense is first in line :)
Why shouldn't I use pfSense as DHCP server in AD environment? We've always worked like that, at work our Domain Controllers are also not the DHCP servers.At this moment I don't want to depend too much on the Domain Controller since the problem with DNS forwarders still persist even now that pfSense is first in line.
-
There are so many problems here…
Honestly mate you need to read a text book and learn how AD works with regards to DNS/DHCP before attempting to change things. Just because you do it at work doesn't make it right either.
-
pfSense is now first router in line, DHCP being handled by AD (not needed but okay..) and I have a NAT rule added that redirects RDP to my Win2k12 R2 server.
This rule is working fine, I also added a NAT rule to forward port 80 to a webserver, but from the outside the server is not reachable.From the inside network the Apache test page is being shown.
Enabled logging on that firewall rule and this is all I get:Nov 13 12:03:07 pfSense filterlog: 80,16777216,,1447409177,xn1,match,pass,in,4,0x48,,119,29486,0,none,6,tcp,52,...(MY_IP) ,192.168.60.5,58797,80,0,S,1624279416,,65535,,mss;nop;wscale;nop;nop;sackOK
It's sending port 80 to the correct webserver ( 60.5 ) but nothing happens (page unreachable).
Turning off the webserver firewall does not make a difference.
What could cause this?
-
The internal interface of pfSense (LAN or whatever) has to be the default gateway on the webserver. Is it?
-
DHCP being handled by AD (not needed but okay..)
DHCP should definitely always be handled by the Domain Controller, for the same reason that DNS should be
AD depends on DNS to do pretty much everything, finding computers and servers by name.
What does DNS do? It translates names into IPs, without which no computers would be found.
Now what does DHCP do? It automagically assigns IPs to a computer with a specific name.
So, if because of DHCP, a computer's IP changes from one day to another, how do you expect the AD DNS entry to reliably update the record for that computer name with its new IP if DHCP and DNS are not part of the same integrated system?
There are ways for AD to work with an external DHCP solution, but they are either going to be less reliable, or very expensive.
The point is that everything related to converting DNS names into IP addresses should be kept within AD.
You're going to have a much simpler life, and a much more reliable solution by keeping DNS and DHCP within your AD.
If you don't understand how AD relies on DNS, and how DNS relies on DHCP (for nonstatic clients), then, as someone said above, you need to read a book.
The only reasons DHCP might be working fine on an external server within your work environment, are
1. They spent a lot of unnecessary time and money making sure that that their DHCP solution integrated reliably into AD or
2. Luck. Since DHCP usually assigns the same IP to the same hostname, if your work computers are not changing much, then everything will usually work. The problem with having an external DHCP server will only really manifest if your set of computers is constantly changing from week to week. -
The internal interface of pfSense (LAN or whatever) has to be the default gateway on the webserver. Is it?
Double checked it and that is indeed the default gateway for the webserver.
-
Squid is turned off for testing?
Do a packet capture (Diagnostics: Packet Capture) on the internal interface and filter the webserver address to see if you get a response.
-
Can you post your NAT rules?
-
Squid is turned off for testing?
Do a packet capture (Diagnostics: Packet Capture) on the internal interface and filter the webserver address to see if you get a response.
Squid is turned on (strange thing is that my Linux VMs NEED to be configured with a proxy or the internet connection is so slow it cannot install anything with yum or get something with wget).
This is the result:
10:42:01.551034 5a:7f:e9:b4:c2:6d > 8a:a1:7f:bb:4c:61, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 5766, offset 0, flags [DF], proto TCP (6), length 52)
192.168.60.5.80 > 145.131.176.116.42237: Flags [F.], cksum 0x4de1 (correct), seq 3932193911, ack 1173879912, win 243, options [nop,nop,TS val 101226568 ecr 10548171], length 0
10:42:01.676477 8a:a1:7f:bb:4c:61 > 5a:7f:e9:b4:c2:6d, ethertype IPv4 (0x0800), length 66: (tos 0x48, ttl 54, id 2620, offset 0, flags [none], proto TCP (6), length 52)
145.131.176.116.42237 > 192.168.60.5.80: Flags [.], cksum 0x48db (correct), seq 1, ack 1, win 1457, options [nop,nop,TS val 10548243 ecr 101226568], length 0See attachment for the NAT rules.
Strange thing is that the RDP NAT rule works like a charm.
-
Maybe your outbound NAT isn't working correctly now, after you have changed the WAN IP.
If your outbound NAT is set to do automatic rule generation or hybrid, go to Firewall > NAT > Outbound and just hit the save button. So the rules should be updated. If required reboot pfSense.
If that didn't help post a packet capture of WAN if.
-
I have had problems with using that alias in the destination address field. Try changing it to the WAN IP address and retest.