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.

Obviously the IP you deleted on pfSense is routed to another one which is still assigned to pfSense WAN or the ISPs routers ARP table still isn't refreshed.

What we are here for ;)  Glad you got it sorted.. The actual exchange of info is normally the hard part.. Always a piece of the puzzle missing it seems..  To be honest I don't recall an issue with port forwarding that was not actually pebkac..

Not saying there hasn't been any.. But I have been around these forums for a bit, lots of versions of pfsense - lots of posts.. And do not recall a port forwarding issue that was not peback related.. Common issue is traffic isn't even getting to pfsense wan - so how and the F could it forward anything ;)  The hard part is getting the info needed to figure out what the user is missing..

:P Both my LAN and my Opt1 networks are added to the VPN server config…I didn't mention that in my first comment. One of the posts somewhere in this forum suggested to use NAT which didn't make much sense but I thought I might try anyway.  I'm assuming PFSense has a routing table like most routers so my initial thought was that it had to do with the rules.  Thank you for the help anyway.

FYI, I was able to find the problem but it was a hardware related error.  Thanks again!

I'm using this setup right now.
I set up a ppp connection, with /dev/cuaU0.0  as serial port. apn, phone number, username and password depending on your 3g provider.
I associated it with an interface.
I created gateway group and set up policy routing like any other dual wan configuration

Sadly, most of those "Bridges" & such sometimes rely on "UPNP" as i currently use Wemo.

has an Odd behaviour of my Alexa not Auto Discovering them when they state it can.

So i had to use Yonomi as a "Middle Man" to allow them to be Discovered.

Odd issue, but a work around has solved this/