Rewriting outbound destination IP

Derelict

All -

I am attempting to rewrite an outbound destination IP address from 10.1.1.1:80 to a 206.190.36.105:80. This is working perfectly on my test stack.

On my HA pair, I get an immediate connection refused. This is because this is on my test bench and its "WAN" is another pfSense that is set to block all traffic to RFC1918 addresses.

Here's what I have:

Firewall > NAT, Port Forward

Interface: WIFI (The LAN)
Protocol: TCP
Source: no settings
Destination: single host, 10.1.1.1
Destination port range: HTTP
Redirect target IP: 206.190.36.105
Redirect target port: HTTP
Filter rule association: None (There is a Pass IPv4 any WIFI net any on the WIFI interface.)

When I telnet 10.1.1.1 80 from a host on WIFI I immediately get a "Connection Refused" This is from the upstream WAN router.

The destination IP address is not being translated. When I run a packet capture on WAN I see the outgoing SYN from the LAN host (with the source IP translated to the WAN CARP IP by outbound NAT) but the destination IP address remains 10.1.1.1.

The main difference between my lab stack that does this perfectly and this installation is that this installation is a HA pair. This installation is also running Monday's development snapshot because of bug 4310.

Here is the outbound SYN and the RST from upstream. Captured on WAN:

21:49:56.216222 IP (tos 0x10, ttl 63, id 25909, offset 0, flags [DF], proto TCP (6), length 64)
    172.21.48.10.54709 > 10.1.1.1.80: Flags [s], cksum 0x92a1 (correct), seq 2343507720, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 894373679 ecr 0,sackOK,eol], length 0
21:49:56.216391 IP (tos 0x10, ttl 64, id 8039, offset 0, flags [DF], proto TCP (6), length 40)
    10.1.1.1.80 > 172.21.48.10.54709: Flags [R.], cksum 0x4ff1 (correct), seq 0, ack 2343507721, win 0, length 0

I am pretty much stumped.
[/s]

Derelict

Just had a thought and…. Turning off limiters makes this NAT translation work. Turning them back on breaks it again.

mer

Sounds like PF is getting the packets before your stack modifications.

What about a redirect rule, would that force a change in the dest addr?

doktornotor

There is nothing new here. Limiters applied on NAT -> broken.

jwt

Limiters with NAT now work.

https://github.com/pfsense/FreeBSD-src/commit/1d722dd06892ee05b1117ba6b3454baeec5f2690