So that IP answers ping, but no dns - not udp or tcp, don't even get a syn,ack if try tcp.

So either the traffic is not even getting to you for dns, or your forwards are wrong..

If you sniff on your wan I can send queries that you would see, and then on your lan you should see pfsense send on the traffic and your box respond.  This is really click click sort of stuff.  I can pm my IP to you so you know what IP to be looking for as you can see in the bottom pics starts with 24.13

So look, click click port forward tcp/udp 53 to my box running bind.  Now it has NO ACLs to allow queries from the public net, but you see that it answers with REFUSED.  So connectivity is there.

then the next too are sniffs on the wan interface showing my remote box doing a query and getting an answer.  And If I snff on the lan you see the remote being sent on to my private IP 192.168.1.7 and it answering.

porforwarddns.png
queryanswred.png
sniffwan.png
snifflan.png
porforwarddns.png_thumb
queryanswred.png_thumb
sniffwan.png_thumb
snifflan.png_thumb

I want the NAT translation to take place on the WAN interface. Basically i want the following to happen:

LAN Subnet 10.0.0.0/24
HostB on LAN: 10.0.0.5
HostC on LAN: 10.0.0.10

WAN subnet: 192.168.190.0/24
WAN interface:192.168.190.10
HostA on WAN:192.168.190.20

Host A has a static route to 172.16.10.0/24 with next hop 192.168.190.10

Host A attempts to connect with HostB on 172.16.10.5, pfsense(192.168.190.10) translates the destination to 10.0.0.5. HostB sends a reply back to 192.168.190.20(hostA) with source 10.0.0.5, pfsense(192.168.190.10) translates the source to 172.16.10.5.

Host A attempts to connect with HostC on 172.16.10.10, pfsense(192.168.190.10) translates the destination to 10.0.0.10. HostC sends a reply back to 192.168.190.20(hostA) with source 10.0.0.10, pfsense(192.168.190.10) translates the source to 172.16.10.10.

I think he means Advanced Outbound NAT.

You need to set outbound NAT rules that specify a different external NAT address for each source subnet.

The only way I can see to port forward to two internal systems is by using a load balancer. The load balancer splits the inbound traffic among a number of hosts behind it. So, for instance, you would have one port forward on your firewall pointing to the internal IP of the load balancer (I've used the incredibly simple-to-use ZenLoadBalancer for just this purpose), and then set up two or more hosts for the load balancer to forward the traffic onto. Useful if you're splitting http traffic load between hosts in your DMZ. If you don't mind editing config files, then HAProxy is also a very good load balancer - used by quite a few large, professional organisations.

If you're limited on external ip addresses then just nat the web server. Http has to be the most accommodating protocol ever.

@kejianshi:

Because port forwarding services to the wan like IP cam isn't smart…  Its the opposite of smart...
Its begging for bad things to happen, especially depending on what these cameras are pointed at.

I disagree with this but to each his / her own. If it is done right I don't see an issue. Any system can be hacked as we have seen over the past year. If you want a system to be truly safe then keep it in the box. I have installed Hikvision Cams just use the tool from the website to change the username / Password for each camera. Don't expose the cameras to the Internet. Make sure you are not using the default username / password for your users on your NVR. Your NVR is really just a Web Server.

As far as ports that need to be forward you never mentioned the model number but a quick bing search shows that ports 80 and 8000 should be forwarded to your NVR. I personally user Blue Iris for my NVRs.

Again I'm not arguing that VPN is the safest solution, but sometimes I think we have a tendency to over engineer a solution to a really simple problem. A strong password and not using  a default port number is all you really need.

Both solutions will work, just depends on how you want to attack the solution. 8)

BS it does.. There is not helper so if you want passive ftp to work with server behind pfsense - the passive ports the ftp server is going to use have to be forwarded.

It took all of 2 seconds to setup filezilla server to work.. Here see this thread.

https://forum.pfsense.org/index.php?topic=88057.msg486033#msg486033

Are you sure you can ID the traffic with a source port?

Your solution is clearly more secure.. But this old school method works as well - if not your doing something wrong ;)

It's going to check your public presence only.  It can't easily tell if you're behind some NAT devices.  So even though you're running a port scan from your PC behind the firewall, the scan is really targeting the firewall and not your PC.

Wouldn't an Outbound NAT rule do just that?  I have an Outbound NAT rule to make it look like my mail server is sending mail using the same public IP address as our inbound mail scanner.  I have the public IP address port forwarded to the mail scanner, and the Exchange server set to talk outgoing on the same public IP address that the mail scanner uses for incoming.

i tried adding rules that allow all traffic from lan to wan and wan to lan, so in theory, the firewall should have been "off" yet it made no difference.

Not really.

You need to understand fully what interface rules go on and why.  Start here and ask away:

https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting

Do you get public IP addresses on your WAN?  You also need to disable the private address filtering on WAN if not.  This also might apply to receiving return traffic from the 172.24.0.0 172.26.0.0 networks.  I'm not sure if that checkbox blocks states created going out.  Bottom line is if it's not unchecked and you need to talk to private addresses outside, uncheck it.

ETA: I see the 12/8 public address scheme you get on WAN.

When a host on the outside says, "where is mail1.example.com?" they get 209.224.34.45
When a host on the outside says, "where is mail2.example.com?" they get 209.224.34.46

Do this by placing the A records for the VIPs that get forwarded to the mail servers in your global DNS.

When a host on the inside (including your mail servers) says, "where is mail1.example.com?" they get 192.168.10.3
When a host on the inside (including your mail servers) says, "where is mail2.example.com?" they get 192.168.10.4

Do this in host overrides in DNS forwarder / DNS resolver, or in your windows zone.

If your windows DNS can't do this, then let it handle internal queries with internal answers and farm out the external, global DNS to he.net, dyn, zoneedit, etc.

Snort,

I think we need more details about your setup. If you have a setup where you have been allocated a block of IPs and your server and WAN interface on the pfSense are using IPs from the same IP block then we need to know what you are trying to accomplish.

If my example is the case then you would simply set both to use the same gateway IP. However, I assume that you want the server behind the firewall and/or have some other more complicated needs.

If your issue is that the server needs to be able to access resources behind the pfSense firewall then there are several options that will depend on your needs.

If the server does not need to be behind the firewall.

1a) You could connect a 2nd interface on your server to the LAN network, set a LAN IP on that interface and if you have other IP blocks behind the firewall you can set routes to traverse the 2nd interface on the server for those blocks.

1b) The same as 1a, but for the ip blocks you want to reach that are behind the firewall, you set routes on the server to get to those IP blocks via the IP on the WAN interface of the firewall.

1c) You may be able to set the gateway on your server to the IP on the WAN interface of the pfSense firewall. I have never tried this and it's really not the best practice thing to do.

If the server needs to be behind the firewall.

2a) The right way is to get a 2nd block of IPs routed to the IP on the WAN interface of the firewall by your ISP. Then you create a LAN interface on the firewall using the routed IP block.

2b) You could configure the WAN and LAN interfaces in bridge mode and then systems on the bridged LAN interface could have public IPs. I do not know if this will work for your specific setup. I have not used this setup, so I don't know who well this works if you still want some systems using NAT or if you want the firewall to respond to a public IP for management (ssh/http/https), VPN, etc. Using alias IPs and/or other IP types it seems like it's doable.

2c) If 2a is not an option and 2b adds more complexity for all your other systems, then using a Proxy ARP IP may be the solution. I am not vary familiar with Proxy ARP, from my reading about it, that may work for this situation. I am not sure how to configure it. I think you would configure a LAN interface on the firewall for a subset of your larger IP block like a /30. Then the server would need to be connected to that interface and you would have to create a Proxy ARP entry for the server IP or the /30 on the WAN interface. This is just a guess on how to do it and I don't know if pfSense would except the setup I have described, but that could mean my way is just the wrong way, not that there is no pfSense solution.

Good luck,

Rhongomiant

Sounds like to me you don't really know what you want.

I can only answer you questions as asked - can't read your mind.  You could have 100 servers, you could hae 1 server serving up 100 different fully qualified domain names via host headers, you could have 1 server with 100 IP address.

Comes down to the same thing you only have 1 public IP.  If you want to use the same name site.domain.com to get there you can only distinguish via ports like shown.  Or if you want to use a reverse proxy to see sitea.domain.com and send to 192.168.1.100, and siteb.domain.com to 192.168.1.101 be it 1 server or 2..

What you can not do is have pfsense out of box know that you want to send sitea.domain.com to 100 and siteb.domain.com to .101 since it only sees the public IP your hitting and a PORT..

You are 100% correct.  The WAN interface did not have a default gateway selected in the WAN interface page.  The default GW was there though in the routes table, so I just selected it in the WAN interface page and now automatic outbound NAT properly creates the auto rules.  Thank you for your help.

I have also seen some pages use some JavaScript and/or WebRTC trickery to find the local IP address, but usually a proxy and X-Forwarded-For is the culprit.

Ah, thank you!  sorry to CMB, I sware I saw the "thing" grey out and can not move.  but I moved it now, I'll go test, probably should work now.

Thanks again for the help!

:D

Problem solved problem solved, it was actually the default gateway, I pointed to my server 2 pfSense router and everything works