Port forward and rules not giving any love to webserver inside DMZ

rwoo

I'm having difficulty making port forward work for a web server setup within an OPT1 designated as a DMZ. Probably a simple solution where I am totally missing a key element. I need help. What I want is to be able to access the web server from the internet using a public IP. I've seen similar post on this board and other, but can't seem to make this work.

Here's my setup: Comcast SMC D3G modem –-> pfSense box with 3 nics. 1 nic to LAN and the other to OPT1 designated as DMZ. DMZ is hooked up to an 8 port switch to which is attached the webserver with ports 80 and 22 open. A laptop connected to this switch is able to verify that both ports are open and that sshd and httpd are active.

Comcast has allocated the following:
Gateway 173.X.X.94
Subnet 255.255.55.240 (/28)
Static IPs 173.X.X.81 through 173.X.X.93
Currently, all services on the Comcast modem is turned off, including NAT, allowing all traffic to flow thru.

Here are my settings for the interface:
WAN 173.X.X.93/28 with gateway set as 173.X.X.94
LAN 192.168.1.1/24 with gateway = none
DMZ 192.168.2.1/24 with gateway = none

The webserver is has a fix IP of 192.168.2.10
I setup a proxy arp VIP as 173.X.X.92/32 which will be for this webserver.

I've attached images of my port forward, WAN and DMZ rules; just the basics without my many tried rules which failed. I realize that I may be missing a much needed rule or two. Can you help?

![pfsense.localdomain - Firewall_ NAT_ Port Forward.gif](/public/imported_attachments/1/pfsense.localdomain - Firewall_ NAT_ Port Forward.gif)
![pfsense.localdomain - Firewall_ NAT_ Port Forward.gif_thumb](/public/imported_attachments/1/pfsense.localdomain - Firewall_ NAT_ Port Forward.gif_thumb)
![pfsense.localdomain - WAN_ Rules.gif](/public/imported_attachments/1/pfsense.localdomain - WAN_ Rules.gif)
![pfsense.localdomain - WAN_ Rules.gif_thumb](/public/imported_attachments/1/pfsense.localdomain - WAN_ Rules.gif_thumb)
![pfsense.localdomain - DMZ_ Rules.gif](/public/imported_attachments/1/pfsense.localdomain - DMZ_ Rules.gif)
![pfsense.localdomain - DMZ_ Rules.gif_thumb](/public/imported_attachments/1/pfsense.localdomain - DMZ_ Rules.gif_thumb)

cmb

Config looks fine assuming the proxy ARP VIP is correct. Check your modem's ARP cache to make sure it's shown in there. If it is, then go to Diagnostics>Packet capture, interface WAN, host the 173.x IP, port 80, start. Try to browse to that from somewhere on the Internet. Stop the capture. If you have no traffic there, it's not getting to you, likely because your modem is blocking it. I'm guessing that's likely the cause. Those SMC modems don't always disable the firewall when you tell them to, sometimes you have to reboot after disabling it, sometimes enabling and disabling it will kick it into shape.

rwoo

@cmb:

Config looks fine assuming the proxy ARP VIP is correct. Check your modem's ARP cache to make sure it's shown in there. If it is, then go to Diagnostics>Packet capture, interface WAN, host the 173.x IP, port 80, start. Try to browse to that from somewhere on the Internet. Stop the capture. If you have no traffic there, it's not getting to you, likely because your modem is blocking it. I'm guessing that's likely the cause. Those SMC modems don't always disable the firewall when you tell them to, sometimes you have to reboot after disabling it, sometimes enabling and disabling it will kick it into shape.

Yes, I have the proxy ARP VIP set to a single address of 173.X.X.92. I did recall reading somewhere that it may be necessary to call Comcast to request that they clear the ARP cache, as this feature is not available through the modems webgui interface. I had hope that this wouldn't be the case as I've read that their tech support is not very helpful. I'll may give it try anyway since you mentioned it.

I just tried the packet capture feature. I do see that the WAN is receiving the request as I browse to my public IP from my iPhone. Here is a sample line from the output:
23:51:45.211211 IP 166.205.136.218.50062 > 173.X.X.92.80: tcp 0
So I guess the modem is letting it pass through. From the DMZ, packet capture draws a blank. Can I assume that I may be missing a rule or that translation is not occuring?

cmb

You just power cycle the modem to clear the ARP cache, if you ever have to. That's fine in this case it appears or it wouldn't show up there. You'll have to change the IP when capturing on the DMZ. and make sure that 2.10 IP is actually reachable from the firewall, Diag>Ping

rwoo

I want to first thank you for your help.

No luck with the packet capture from the DMZ using host 192.168.2.10.
Also, getting 100% packet loss when ping from WAN to 192.168.2.10.
I do get all packets when I ping from the DMZ interface to 192.168.2.10.
Must be a problem with configuration between WAN and DMZ. Any other ideas?

urbangear

@rwoo

Here are my settings for the interface:
WAN 173.X.X.93/28 with gateway set as 173.X.X.93
LAN 192.168.1.1/24 with gateway = none
DMZ 192.168.2.1/24 with gateway = none

why does WAN and gateway has the same IP? shouldn't it be 173.X.X.94 for the gateway?

did you try IP Alias 173.X.X.92/28 assign it to webserver 192.168.2.10 in 1:1 NAT then manually adding a rule in your WAN to forward ports 80 and 22 to 192.168.2.10?

rwoo

My bad. The gateway for WAN is 173.X.X.94. I corrected my original post.

I did not try the IP alias, with 1:1 NAT and then port forward to the same server. Had not seen that combo in any other post. I was trying to avoid use of 1:1 NAT as my understanding was that just port forwarding alone provided the greater advantage of securing the web server. I may give it a try if I can't get port forward to work. But this problem still presents to me a challenge to understand why it's not working with my setup. I must be missing something elsewhere in pfSense. Perhaps a setting that should be enable or disabled that is taken for granted by others but not passed on in any "recipes" for this kind of setup.

One thing that I did try was to change the port that WebGui listens to and to disable WebGui redirect in the advance setting. Still no luck.

urbangear

I setup a proxy arp VIP as 173.X.X.92/32 which will be for this webserver.

but you already setup proxy arp VIP so you need to do 1:1 NAT after that

cmb

You don't need 1:1 NAT (unless that's what you want) for the port forward. Not being able to ping when sourced from WAN suggests your DMZ host doesn't have any or the correct default gateway.

rwoo

@cmb:

You don't need 1:1 NAT (unless that's what you want) for the port forward. Not being able to ping when sourced from WAN suggests your DMZ host doesn't have any or the correct default gateway.

Yes, I don't want to do a 1:1 NAT, if I can get port forwarding to work. As in my original post, DMZ doesn't have a gateway assigned to it. I'll try again with the DMZ gateway assigned to 173.X.X.93, which is the WAN.

rwoo

@rwoo:

@cmb:

You don't need 1:1 NAT (unless that's what you want) for the port forward. Not being able to ping when sourced from WAN suggests your DMZ host doesn't have any or the correct default gateway.

Yes, I don't want to do a 1:1 NAT, if I can get port forwarding to work. As in my original post, DMZ doesn't have a gateway assigned to it. I'll try again with the DMZ gateway assigned to 173.X.X.93, which is the WAN.

No luck with ping from WAN to 192.168.2.10, the DMZ host, with the DMZ interface assigned a gateway of 173.X.X.93. Couldn't capture packets either. I am able to ping the host from DMZ through. I double checked the DMZ host network configuration, which is a centos box running both web and ssh services:
Static IP of 192.168.2.10
Mask 255.255.255.0
Gateway 173.X.X.93

I am still able to ping the DMZ interface from WAN, just can't get thru to the host. I'm not sure what is blocking this. Do I need to specify a rule to pass thru the DMZ interface? If so, how do you recommend I configure this?

Otherwise, I'm thinking there may be a hardware problem with my nics or perhaps a bios issue with the pfSense motherboard. What do you think?

cmb

No you don't want a gateway selected on the DMZ interface, that will break things, that's strictly done on Internet connections. I was referring to the default gateway on the actual web server. Can the web server get out to the Internet?

Since you can ping from the DMZ interface, it's not in any way hardware-related.

rwoo

I'll have to check tomorrow when I return to the office. I'll reset DMZ gateway to 'None'. As I recall, I could not get system updates from the centos box during it's setup within the DMZ, so I suppose internet connection is not working. I'll check on that tomorrow.

cmb

Just wanted to follow up here for others who may want to know the cause, rwoo bought support and we walked through everything. 3 separate main issues here.

The VIP on WAN was conflicting with another device. Turning the packet capture on WAN up to "Full" detail and checking the destination MAC address showed that. That's a good thing to keep in mind when troubleshooting things along these lines, seeing something in a packet capture on WAN doesn't necessarily mean it's being directed to the firewall, if the destination MAC isn't the firewall's (i.e. you have an IP conflict), then it isn't going to pick up that traffic and forward it.
The DMZ server's default gateway was wrong.
the host firewall on the DMZ server was blocking off-subnet traffic, so you could browse to it from the same subnet, but not from any other network.

Took care of those and it's all working.