You are SO right about that part!  Now that I just put none under upstream gateway for pfSense it now shows only WAN rules under the NAT.  Thanks so much for that!  I don't know why I had it like that.  Thanks very much for helping me!  I very much appreciate it!  I will test some stuff later and let you know!


Filtering Bridge could be an option, maybe?

OK. Looks like all is working fine now. I think the only big change I made was on the OPT2 outbound rule. I changed it from "IP Proto TCP any" to "IP Proto any" and that seemed to do the trick. I'm actually not sure why I had that set to TCP in the first place, so thanks for looking things over guys. :D

There are two things you have to worry about: Translating the traffic and making sure traffic for the translated subnet returns back to pfSense

1. Add 1:1 NAT to map the LAN subnet to the translated subnet on WAN (interface = WAN, external subnet IP = translated subnet address, internal IP = your LAN subnet with the right mask, destination = the remote VPN subnet so it won't affect other traffic leaving)
2. Add a static route in the upstream device (not this pfSense box!) to send that translated subnet to the WAN IP address of pfSense

Since it hits the VPN on the next hop up that should still only end up being one layer of NAT

I am also confused… What are you doing here??

1  PFSense1-XXXX1-X1.XXXXX.com (192.168.1.1)  0.211 ms  0.181 ms  0.196 ms
2  PFSense1-XXXX1-X1.XXXXX.com (192.168.1.1)  0.301 ms !H  0.289 ms !H  0.276 ms !H

Why would you have 2 hops going to the same IP?

Trying to nat reflection is a bad idea.. if you have outside IPs that your natting to inside IPs that is fine..  Why would you try and traceroute to the public IP from inside pfsense or even from pfsense if that IP is directly on pfsense?

With muswellhillbilly here - drawing and full info is very helpful in helping you do what ever it is your wanting to do.

@johnpoz:

Well how are you going to access your other interfaces if your sending all data out your wan?

This first statement made me go d'oh! Thanks, this was a very easy fix!

Nothing significant changed there. Proxy ARP VIPs still work for NAT like they always have. At some point in 2.2.x there was a problem people had where using Proxy ARP VIPs could crash the OS, but that was fixed in 2.2.5 and wouldn't have altered the functionality of Proxy ARP VIPs.

Without more info to go by, it's hard to speculate as to what might have happened.

Yeah I am curious what logs as well.. What do you mean you have them set to maxium size??  There is no setting in pfsense gui for log size that I can recall.  You can set how many lines of the log to display..

What are these logs filling up with??  Noise?  Maybe look to reducing the noise logged, or just plain reducing the noise its seeing by fixing whatever is causing the noise.

What else are you running on pfsense - what packages?

The source address in your rule shouldn't be WAN, it should be 'any'. Not sure about how your router is set up so if you need to make any adjustments there, you're on your own.

If you have to obtain them via DHCP, that's your only option.

I get what your saying and that makes total sense.  Thanks!

OK, I figured this out.  I set the IPSec DHCP to run from 192.168.5.50 to 150 then I set the OpenVPN interface to run at 192.168.5.192/26 which leaves the DHCP at the top end of that /24.  I am now able to OpenVPN into the box and cross over into the IPSec VPN.

Good to hear.

Thank you for actually checking the things on the list instead of just saying you did and saying it still doesn't work!

Just to be clear your WAN port has a /24 netmask right?

What is this about another /24 and a /22?

You can disregard that, yes our WAN has a /24 
… the other /24 and /22 are separate networks from another provider (which will be handled by separate hardware)

Thanks for your description, that makes it a lot clearer.  Will work with provider and see if they can provide something similar.

tutorial with screenshots

http://meow.tpfnd.cat/node/20

@kncar77:

Voila, all was working and the traffic was routed through the new VPN by default but how? Under System Information -> Routing it says WAN is default, something I'd expect I guess as otherwise how would the VPN client be able to connect?

The existing Firewall rule was just allow all to all from all * * * basically..

I guess you get the default route pushed from the vpn server. This can be checked in Diagnostic > Routes while the vpn client is connected.

@kncar77:

So does it come back to the order of the NAT outbound rules?
But the top NAT rule is the WAN and immediately below is the VPN rule and still the VPN is the default?
Does it read from bottom up and first hit becomes the rule? Or vice versa, the last becomes default?

The outbound NAT rules are checked for matching their constraints from the top to bottom likewise the firewall rules. But the WAN rules don't match for vpn traffic, because it's going out the vpn interface, since it's routed to the vpn server by the default route mentioned above.

Will a video do?

https://www.youtube.com/watch?v=28dmUzOGI50

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?