OpenVpn "inbound" NAT

[Weppa]

Hello everyone

I have a virtual Pfsense firewall protecting boxes that are dual homed
Let's say all ETH0's of the boxes are on LAN (192.68.0.0/16) , and all ETH1 are on OPT1 (10.31.0.0/16)

I have OPenvpn clients connecting on the firewall. They receive the two network (push routes).

all ETH1 don't have a default gateway
Which means that when they receive traffic from the VPN, going in thru ETH1, answer goes back thru ETH0

Actually this works (?), but of course that's no want i want.

Is is possible to "inbound NAT" the traffic from openvpn clients to 10.31.0.0 so that traffic seems to have come thru 10.31.0.1 (firewall IP on that LAN)

I've tried every combination possible of NAT rules but it never works
I tried adding the rule on WAN, on OPT1, on openVPN, with source IP : openvpn client network, and destination IP in OPT1, and the traffic is never NATTED

Any help appreciated :)

[Derelict]

Easy. Connect to those hosts using the address on the subnet that has the default gateway back to pfSense.

But to do what you want you want an outbound NAT entry on OPT1 translating the traffic sourced from the OpenVPN clients to a NAT address of 10.31.0.1.

[Weppa]

Hi and thanks for helping me,

I can assure you I tried every combination on earth of such NAT rules, and they never work :(

DO I need to reload openvpn maybe ?
My NAT rules are simply discarded…

The only thing I havent tried yet is to reboot the firewall, I'm really going mad :(

[Weppa]

Okay it's even weirder than I thought (and might well be a bug in pfsense)

Actually this openvpn client receives his ip thru a specific override (but it's just a static IP in the openvpn range !)

All other openvpn clients , in the same range, are indeed NATTed (simple NAT rule on OPT1 = sourc = openvpn clients, destination = OPT1 network, translated as interface IP)

Only that specific client, who gets his IP from an override, completely bypasses the NAT process

[Derelict]

Outbound NAT doesn't care or need to know whether this is a static address, OpenVPN, IPSec, etc. All it sees is the source IP address.

If it didn't work you did it wrong. Post screenshots.

[Derelict]

@Weppa:

(and might well be a bug in pfsense)

Damn that's annoying.

[Weppa]

Okay I shouldn't have jumped to the "bug" thing. Let's forget about it. But please also admit that you know absolutely nothing about my background and you shouldn't always see a 4-posts-user as a newbie. I'll skip the CV.

My NAT rules are OK.

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

I'd be happy to provide screenshots so that we can dig into this a bit deeper (I may have done something wrong), but the fact remains that currently, with a proper NAT rule, I've got traffic MATCHING the nat rule that is not NATTED. There's zero confustion here ; tcpdump doesn't lie.

But I first have to "anonymize" the infrastructure as bit, as this is a live env.

Please don't get me wrong, I'd be glad to dig into this even if I found a workaround.

[Weppa]

Rebooting the firewall (the last things I did not do) solves the problem…

If anyone want to reproduce, feel free : I imagine this set up should suffice (no need to be dual homed)

connected Openvpn client ping something on a LAN, add a NAT rule matching this traffic to NAT it to exit interface's IP -> nothing happens. traffic that should be matched is simply not matched.
I'm not sure of the client has to be overriden or not (i'll try)

Until "something" happens ( state table ? ) that makes it finally work.

I'll try to do it on a VM on my mac.

[Derelict]

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?