Traffic from "overriden" openvpn client 172.16.0.255 (fixed IP for his CN) is not NATED Traffic from non overriden openvpn clients (in the same 172.16.0.0/25) range is NATTED Right there you call 172.16.0.0/25 the SAME RANGE as 172.16.0.255, which it, of course, is not. And 172.16.0.255 is not a valid IP address for /24 either. So what's the deal? This is why we want screenshots.  We're dealing with RFC1918 addresses. There is practically zero reason to anonymize anything. I never have to reboot any pfSenses to make things like this work. If I did it would be nearly worthless to me. Do you have any packages or limiters configured?

Solved it, forgot to set the upstream gateway under the WAN interface!

As I've been digging through this the last few days, I have come to the conclusion that the source-hash pool option needs an optional key in order to provide consistent hashing. Unfortunately this isn't available in the pfsense ui, however you can specify a custom value by changing config.xml <poolopts>source-hash 0x2fc76c65e927fcf98f56743d776747cc</poolopts> This value is randomly generated unless specified every time pf is reloaded, so if you need consistent hashing you have to provide it. For our setup it is absolutely crucial that both servers use the same key. I will also say that what we've opted to do, in order to not be limited to max # of vhid, was to for each server on the outside configure only one CARP address. Then we split the NAT CIDR range on the outside router with static routes to each CARP vip that's then redistributed into our infrastructure using OSPF. I have submitted a pull request to the pfsense github repository for some webui changes https://github.com/pfsense/pfsense/pull/2743

how 1.2.3.4 a port???  that is not a valid way to represent a post.  I don't even think the gui would let you put that in, Also do you have source port as 80 as well???  that is not how it works.. Post up pic of your rules both nat and wan, not this ascii art please.

I saw your pm, but could not post pictures.. Here see how I can access my printer on different segment, even when I connect to my vpn - because I have a route! Se my public IP is now showing vpn IP. [image: printeraftervpn.png] [image: printeraftervpn.png_thumb] [image: publicviapvpn.png] [image: publicviapvpn.png_thumb]

System > Advanced, Admin Access tab Protocol: HTTPS TCP Port: blank WebGUI redirect: unchecked (enabled) Firewall > NAT, Port Forward tab Interface: WAN Protocol: TCP Destination: WAN address Destination port range: HTTP Redirect target IP: 172.26.0.100 Redirect target port: HTTP Description: Pass HTTP to web server Filter rule association: Rule NAT Pass HTTP to web server (Auto-created) http://172.27.0.5/ I get the forwarded web server. I have no idea why people say they get the WebGUI. Probably testing from inside or something equally wrong.  

It is so much easier than all that. Part 1: Go to Services DHCP Server and scroll to the bottom. Add a DHCP Static Mapping for the device.  While doing so, in the Edit static mapping page select the "ARP Table Static Entry" option.  Not to be confused with the "Static ARP" option on the main Services DHCP Server page. That will cause an ARP table static entry to be created and will survive reboots, updates, etc. because it is saved in the config. Part 2: (optional) To forward WoL packets through the NAT from the outside.  Create a static mapping for MAC FF:FF:FF:FF:FF:FF with an IP address of something like maybe 192.168.1.254 for example.  Because *.255 (broadcasts) won't be forwarded.  But *.254 will be. See screen capture attachments. With this set up WoL magic packets sent to the WAN address on the specified UDP port are forwarded as a broadcast on the LAN. Restriction to trusted source addresses and networks is highly recommended. [image: Snap1.jpg] [image: Snap1.jpg_thumb] [image: Snap2.jpg] [image: Snap2.jpg_thumb] [image: Snap3.jpg] [image: Snap3.jpg_thumb] [image: Snap4.jpg] [image: Snap4.jpg_thumb]

Found the solution today! You only have to set a rule under firewall -> nat -> outbound that looks similar to the default rule for port 500. Of course with port 4500 and my lancom behind the pf can digger his tunnels  ;D Hope it helps other people!

Hi John, Had a quick play with what you suggested and it's currently working just as I had hoped (I have a rule for 443 as well). Thank you for the help an pointing me in the right direction it is much appreciated :)

Case closed. Suricate was the cause of all the problems we had. I've added the IP addresses that were not NAT-ed to the pass list and it worked. Topic can be closed.

Is he a 13 year old girl on her first period as well?  Frightening??  Oh the bad man on the internet said I was doing it wrong ;)  ROFL…

well for starters there is an error with their cert its only good for .com not .br Even if you add exception for the site it doesn't load… Not a pfsense issue.

Have you tried running a telnet from outside to your external IP (Globe) to see if you can connect to port 23? Also, might be worth checking the default gateway you've set on 172.16.0.1 - make sure it's pointing to the PFS, otherwise your outbound traffic won't route back out successfully. I'm also not sure what the second rule down is supposed to accomplish.

Thanks for your help, I'll give this a go…!

what doesn't make any sense is why when he shows the rules there is no dst port in it.. So I just fired this up as quick test… I forwarded 4000 to 22, then validated that when I check 4000 it shows open by sending traffic to my box on 22..  You'll that the firewall rules show 22 to my 192.168.9.7 IP.. The nat rules are evaluated first, and then it hits the firewall rules from my understanding, so that actual dst port needs to be open. Looks like to me there is UDP traffic to 7999 as well.  What is the point of the redirection??  Why don't you just forward port 8000 in??  Its not like you have any other ports being allowed on 8000 so you have to use a different port. [image: rulewrong.png] [image: rulewrong.png_thumb] [image: redirectportforward.png] [image: redirectportforward.png_thumb]

@KOM: Everyone: The use of terms of endearment are common with speakers from the Middle East.  While they may appears out of place to us in a technical discussion, please don't mock them for it. Noted. Though in truth I thought this was more a Google-translate error and was really gently mocking what I thought was a technical mishap on their part.

@johnpoz: Because your inside your network.. You need to TEST port forwards from OUTSIDE your network.. Thank You Already Tested and Working!