@Chromatics:

When you were running tcpdump, you could see each packet's logs.

Were you able to see from xn0 with incoming packets with destination as public IP : port 80?
And what about outgoing packets with source as public IP : port 80?

Were you able to see from xn2 with outgoing packets with destination as 10.1.10.102 : port 80?
And what about incoming packets with source as 10.1.10.102 : port 80?

Were you able to see from the interface of webserver with incoming packets with destination as 10.1.10.102 : port 80?
And what about outgoing packets with source as 10.1.10.102 : port 80?

Thank you for the all responses and suggestions! Helped me debug network

That's right.

Configuration causing problems:

#1: DLNA enabled on WAP clients, uPnP enabled on router

Configuration seemingly not having problems:

#2: DLNA filtered / disabled on WAP clients, uPnP enabled on router
#3: DLNA enabled on WAP clients, uPnP disabled on router

I'm currently operating under configuration #3 and not noticing any issues.

Mike

If you want to solve this with static routes you have to add a route to each LAN host directing the vpn tunnel subnet to pfSense.

If you want to do it with NAT, you've to add an outbound NAT rule to LAN for the tunnel subnet.
Set the outbound NAT rule configuration to manual or hybrid mode. Then add a new rule:
Interface: LAN
Source: VPN tunnel network
Traslation: interface address

This NAT rule translates source addresses of packets from the vpn subnet to the LAN address, so responses are addressed back to pfSense.

Just my 2 cents and not new solution for you.
I recently configured my PBX with pfSense and I have no issues so far.
I only set NAT outbound rules as static, no need to set any port forwarding. Once PBX got registration, the state is well shown and kept alive. Outbound and inbound calls work fine.

Yes. with a 1:1 you just pass the ports you want to the inside address using WAN rules.

If you did want to translate a port, say, you had a 1:1 NAT for wan_address:inside_address and you wanted wan_address:8080 to be forwarded to inside_address:80, you could still do a port forward. Port forwards take precedence over 1:1 NAT so it will be honored. The firewall rule in that case would need to pass destination inside_address:80.

If I type the list name (it doesnt auto select or show it in the popup list) it does appear to work (ie the IPs pop up in the full NAT rules list)

Your current set up uses a Linux specific hack that is not supported on FreeBSD and therefor not on pfSense either.

@harleyip:

If the source is 19bit with NAT address is 24bit and the translation pool options is Source Hash with static port, will it be possible to have duplicate outgoing entries (same NAT address and port number) for multiple source hosts? If so, how to prevent this happen assume the static port is required. Many thanks.

The 19-bit vs. 24-bit part of your question makes no sense at all. A /19 IP address is just one IP address with 65536 different ports (different sets for TCP and UDP though) just like a /24 IP address is. The CIDR part (or netmask in the older way of expressing the same thing) only denotes what kind of subnet (maximum number of hosts in other words) is used in the directly connected network segment.

For example if you have a host on the LAN that uses UDP port 12345 for sending data and you use static port pfSense would allocate UDP port 12345 on the WAN interface for the connection. Any other LAN host trying to use the UDP 12345 with static port would collide with the first host, no it wouldn't work. The PF packet filter and address rewriting engine doesn't have an option to first allocate a source port dynamically but then to keep it static for the subsequent connection from the same LAN host, that would solve this problem nicely if it was available.

When i get it to work the default gateway for Plex is WAN. I have a port forward rule for plex on the WAN. with this set up I am able to access Plex from outside the Plex Media Server's local network.

The way I would like it to work is having the default gateway for Plex be the VPN server (VyprVPN)(LONDON) and be able to access it from outside the local network the same way it works via the WAN.
You can see the attachment for my NAT rule. I currently have the (LONDON) NAT inactive as I am routing Plex via the WAN.

NAT.png
NAT.png_thumb

That solves the issue.

But is there any way to this with a more proper setup?

Would you be more specific?

I know and I encountered problems by asymmetrical routing before. It is harmless, until it passes a stateful firewall when going out and does not pass it again when returning or vice versa. Usually the firewall blocks returning packets not registered in its state table.

And I think this is not the case.

Of course, the path before the packets reach pfSense host might be different.
(Server A) 192.168.1.51->192.168.1.100->192.168.1.1 (pfSense Host) == Not works
(Server A) 192.168.1.51->192.168.1.1 (pfSense Host) == Works
(Server A) 192.168.1.51->192.168.1.100->192.168.1.50->192.168.1.1 (pfSense Host) == Works

Because in all case the packets will reach the pfSense host via 192.168.1.1 first and go out via 172.17.0.5 and when they returns it will reach 172.17.0.5 first and 192.168.1.1 later.

@viragomann:

You have multiple CARP VIPs on WAN? That's not necessary and not recommended any more. CARP VIPs make much overheads on the network. It's better to assign just one CARP and IP Aliases hooking up on it.

That is how I set it up. (See the second paragraph in my original post) Thank you for double-checking that aspect, though!

@viragomann:

That's the normal behaviour of pfSense. You don't have to care about this.
The outbound NAT is just applied on connections that are initiated from inside your network.

That answers my question perfectly. Thank you!

– Caleb

Hi, oops! didn't realize there was a gaming section..

My Lan rules were default from fresh install :)

"=honestly i don know how to check this"

Sniff on lan where your zimba is in pfsense on diag, packet capture.  Then try to talk to your zimba from some box on lan 2.. Do you see the SYN go out, do you see the syn,ack come back or do you just see a bunch of syn and retrans?

This is really basic network troubleshooting 101..

if you do not see any syn leave pfsense to your zimba box.  Does pfsense even see the syn.. Packet capture on lan 2 interface this time - repeat the test.  Does pfsense see the syn??  If not then your device on lan 2 is not sending to pfsense as its gateway, etc..

If you see the syn come into lan 2 but not go out lan 1 - then pfsense either is not allowing the connection or is sending it elsewhere - like out your wan for example because you have maybe a gateway set on your lan 2 rules?

Post up your rules and we can look..  Can lan 2 talk to other devices on lan 1?  If so then its a zimba thing.  Can lan 2 device ping the lan 1 IP of pfsense?

That's not as trivial to do. It's better you let this do the network engineers.

You can check if the VLAN is assigned to pfSense in Status > Interfaces. The VLAN interface should be listed there with its subnet and mask.

A VLAN has to be terminated at two sites. One can be the pfSense, the other site can be a switch or a computer. So as you say, the device which owns 172.16.40.1 is connected to a VLAN, so is the VLAN set on the device itself? Have you set it yourself?

@johnpoz:

Turn off nat reflection..

That did the trick.

Thank You very much

Close out as solved…

OK, thank you all for helping me out, and especially for goading me into finally setting up the  openvpn server.  Particularly johnpoz, goader-in-chief, it wasn't as bad as I feared, I managed to stop the bleeding from my ears fairly quickly and got it running without too many problems.  And even doktornotor, thanks for trying even if we didn't quite communicate adequately, I apologize if I got I got a bit too irked.

You mentioned you are running your LAMP server on customized port, but if I check your pic earlier, the port listed in HTTP.

What's the port you are using on your LAMP Server?

What's the URL you use to hit it internally?

What's the URL you use to hit it externally?

Rather than doing NAT for internal access, use a DNS override as it works much smoother and removes a connect to the pfSense router and back.

As a side note, I wouldn't really put my WebGUI available on the WAN, I'd just configure OpenVPN or something and connect via that route as it's much more secure.