Kazzuja, did you manage to resolve your issue? Especially the part where you can ping the external IP…

I have several WAN interfaces (8 at the moment) and it should listen on just 1 interface. I'll try disabling NAT 1:1 for this interface and do portforwarding. Otherway around it is working fine; I can reach the internet from the local server, but it is still strange NAT 1:1 works fine for 7 interfaces but not for number 8. Thanks, Roger

I guess they need to provide a firmware update, with the new address.  ;)

It can be done with squid as a reverse proxy (I did it). It can be done with HA-Proxy (I'm doing it ;) ) In HA-Proxy you will need two backends. One for each server you want to forward trafic to. (you can specify them on IP addess - no nned for DNS for that) You will need one HA-proxy frontend listening on your wan address port 443. On that frontend I would configure two ACL:S one that says that if the hostname is ws1.domain.com send it to backend 1 the other one would handle the ws2.domain.com hostname and send that to backend 2.

@isolatedvirus: PFSense as far as i can tell ignores its own PBR, and uses the routing setup in System->Routing @Derelict: Traffic generated on the firewall itself does not enter an interface and that leaves only the routing table. thanks for confirming.

I found the solution. In a virtual network there are no checksums. So what I had to do was to disable tcp checksum offloading. Here are the two sources with more information that I used: https://forum.pfsense.org/index.php?topic=88467.0 https://serverfault.com/questions/581265/disable-tcp-checksum-offloading-on-kvm-virtual-network

Hello. Got similar problem. pfSense2.3.3-RELEASE-p1 (i386) on public IP. WWW serwer in LAN (192.168.1.6) If I use NAT from WAN:82 (or any other port) to port 192.168.1.6:80 - everything works OK. If I want use NAT from WAN:80 to 192.168.1.6:80 it doesn't work - no connection, no errors in logs. NAT from WAN:443 to 192.168.1.6:443 works OK, every other ports (SSH, etc.) - too. Only 80 - not. No service on pfsense uses port 80, I'm sure. Web panel after installation was on port 80, maybe is blocked all the time for some reason? Thank You in advance. Radek

@wupperi: I know I do not have to NAT to do a site to site tunnel. However I do want to masquarade the source IP adresses that come in from the internet through firewall A so firewall B does not see them but natt'ed adresses. So it is a combination of port forwarding to a destination address which is reachable through the tunnel and a source NATting before the packet travels into the tunnel. With IPSEC I could not get it running, however with OVPN for wahtever reason it worked. you should just need a port forward, and a outbound nat rule. Internet source -> Firewall A -> Port forward to host B -> outbound NAT on IPSEC (Match source = !Local Lan Subnets) -> vpn tunnel -> Firewall B -> Route Source 'Firewall A (due to outbound nat) to Host B. youve already got it working though so it seems you're good to go :)

Ouch (and thanks).  I've written Ubisoft to see if they'll provide a correct list of ports the game needs.  Hopefully, they'll answer.

Again you can put the vmkern on any network you want, be it a native untagged network or a vlan via tagging. How many interfaces do you have on the esxi box, how many interfaces do you have on the pfsense box.  Is pfsense running on the esxi box? Do you have a managed or "smart" switch that does vlans? Can you draw up how you have everything connected now?

Update: This has been solved and can be closed. @johnpoz: Can you say hairpin, can you say /2 bandwidth, can you say pointless in such a scenario..  Because he wants to hide his public IP?? WTF??? Why not just host what ever he is doing at IP 1.1.1.1?? Use less bandwidth this way.. Clients get better response, No hokey/borked setup and they don't know about IP 2.2.2.2 ;) which seems is the goal. Yes, this would be a hairpin. It would half the throughput, but the load on said link is negligible. I really don't feel like arguing semantics, so im just going to leave it at hairpinning works just fine in pfsense. He's unable to host locally, and the ultimate goal was to allow web servers to be dynamically provisioned and accessed without requiring constant DNS changes. While it's possible to nat the traffic, there were other constraints that would not be met doing this method. The answer was setting up a reverse proxy, which also adds the benefit of acting as an accelerator.

PM sent.

You can still do it just with a bit if cleverness. Nat incoming connections to 3389 to port 65555, and dont enter a firewall rule to pass, or set the rule to deny. This rule would have to be above your 1:1 nat rules so its matched first. Bam. Filtered rdp in the 1:1 nat scenario. Edit: Oh, nice work-around, I like the idea! But really I think it's time to get my clients to accept either a VPN or limit their RDP access to just trusted IPs or networks. Oh and +1 to the VPN. Way more secure.

pfSense is working as desired. I am sorry that you are not following my notes.

here you go homie. I happen to use PIA so use this as an example. Local 2 would be my neighbor's subnet, so you can ignore that. https://snag.gy/cGyrFU.jpg

@5E: I think NAT is not the best option to have VOIP server. NAT can have same bad influence in VOIP Package and hard to debug. I my opinion just bridge WAN Port with the port that you have your VOIP server. And than you can use the static IP from your ISP direct on your VOIP server. Same Sample info about NAT and VOIP https://www.voip-info.org/wiki/view/NAT+and+VOIP http://kb.smartvox.co.uk/voip-sip/sip-nat-problem/ Hes setting up 1:1 natting, which shouldnt affect VOIP in this scenario. The culprit in this situation would be firewall rules blocking the incoming VOIP sessions.

Absolutely! One way to accomplish this is through VLAN tagging your WAN. If youre running PFSense in VM, this becomes easier to accomplish since you tag the incoming ISP connection (ex: vlan 100) and simply add VM's to this vlan in the network section in vmware, or if using KVM through the dropdown selection for your NIC addition. A bit of fair warning though, passing unfiltered internet to a VM tends to put it at risk of attack, so you'd have to be more vigilant on maintaining the VM in question. Just wanted to make sure you're aware of the risk. The other option is to perform a 1:1 NAT, then allow through firewall rules the specific protocols/ports through to your server. This method isn't "worse" than the first one, it just has different cons. Option1: Con is security. Option2: Con is overhead. 1:1 NAT + Firewall rules would have to be parsed for every connection coming in. This isnt going to be a detriment, but without me known the specifics I can't say for sure if its going to be an issue in your environment. I will say however, that this con doesn't apply to 99% of use cases, because the amount of traffic being passed isn't immense.

If your NAT rules are logging, try doing a tcpdump on the internal interface, and filter by the destination host and port. If youre not seeing traffic, you might want to check your firewall rules and ensure there are rules to allow it to pass. PFSense NATs before it filters (however I'm unsure if its able to ascertain you MEANT to allow traffic to an internal host based off of a port forward lookup.), so remember to make the statement on the WAN side to allow traffic to the internal IP of the destination, and not the WAN address of the firewall.

So just to clarify, please correct me if I'm wrong: You have a webserver which you're trying to access remotely through a vpn. Is the VPN server being hosted on your side, or are you a client (Are connections coming TO you, or are connections being made FROM you to a VPN provider?) It sounds like youre using a VPN provider, but I need clarification. Scenario 1: If youre hosting the vpn server, youll need to make sure that firewall rules are matching, and that you allow access through your VPN config. Scenario 2: If your pfsense box is connecting to a vpn provider, you need to make sure your provider allows Port Forwarding. Depending on the VPN provider's setup (some generate a port for you to use at random, others allow a static port assigned to your user), this may require custom scripting on your end.