"For now I don't care if someone see the cameras." Its not that they can see the video..  Its that they can take control of the device and use it to access the rest of your network and or have the device attack other devices.. Its something you really should be concerned with.. if your users can click an icon on their phones - they can be setup to vpn into your network and be secure. https://threatpost.com/hundreds-of-thousands-of-vulnerable-ip-cameras-easy-target-for-botnet-researcher-says/124192/ https://pierrekim.github.io/blog/2017-03-08-camera-goahead-0day.html#backdoor-account "It affects 1250+ camera models."

Could you elaborate, I have a similar problem in which some users should surf (80,443) on a second external IP. But 1:1 Nat seems overkill for me here. edit: Hi my problem was defining a NAT Port that I shouldn't have done, now it works perfect: http://i.imgur.com/2W7rwyz.png 62.X.X.X is my desired outbound IP that is defined as virtual IP -> IP alias for that one client and port.

could be it ? Because I was trying to access through my external IP.  Does reflexion matter on that scenario? Anyway when I get home I try it out thank you!

Was is running dhcp??  Did it have the same IP as pfsense?  How exactly what it connected in your network?

I think that you have the same problem that me. https://forum.pfsense.org/index.php?topic=127882.0 Can you find a solution?

@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. [image: NAT.png] [image: 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