Tricky inbound redirect with pf

[wbe]

How would you go about writing rules for pf to redirect inbound traffic on a host A to another host B while keeping the original source IP? (Host A will then be the gateway for the response from B to make the traffic return the same way it came in.)

[jggimi]

Hello, and welcome!

I'd use rdr-to. But do I understand correctly that you must avoid using rdr-to due to a topology limitation? Other options may include route-to/reply-to. For more specific help, please diagram the problem.

[wbe]

In my toy example there are three hosts:

• 192.168.0.1 (router)
• 192.168.0.2 (server)
• 192.168.0.3 (client)

The below rule will redirect properly, but the response is dropped by the client. I'm not sure how to make the router (192.168.0.1) change the source IP on the response with pf so that it looks like it's coming from 192.168.0.1 instead of 192.168.0.2. It's important that the server sees the client IP.

pass in proto tcp from any to 192.168.0.1 port 443 rdr-to 192.168.0.2

[jggimi]

As I suspected, you have a topology that prevents the simple use of rdr-to. Your "router" is on the same subnet as your client and server. The client and server can communicate directly, without passing any traffic at all through your "router." It isn't acting as a router in your current topology.

If the "router" has two NICs, then you can deploy two Ethernets each with their own subnets, Then, the system would be a functioning router and rdr-to would be the appropriate solution.

If your "router" only has a single NIC, then it is still possible, but more complex to provision. You would create two logical subnets that share the same Ethernet, using alias addressing as described in ifconfig(8) and hostname.if(5). But there is more to do in PF provisioning. Per pf.conf(5):

Redirections cannot reflect packets back through the interface they arrive on, they can only be redirected to hosts connected to different interfaces or to the firewall itself.

However packets may be redirected to hosts connected to the interface the packet arrived on by using redirection with NAT.

See the rdr-to section of the pf.conf(5) man page for examples and further discussion.

[wbe]

Originally Posted by jggimi

As I suspected, you have a topology that prevents the simple use of rdr-to. Your "router" is on the same subnet as your client and server. The client and server can communicate directly, without passing any traffic at all through your "router." It isn't acting as a router in your current topology.

I can see this now. The response from the server passed directly to the client, the "router" was not involved at all.

Originally Posted by jggimi

If the "router" has two NICs, then you can deploy two Ethernets each with their own subnets, Then, the system would be a functioning router and rdr-to would be the appropriate solution.

I followed your advice, and with the same pf rule - with just the target IP changed, since I put the server on another subnet - it works as I had hoped. Thank you jggimi.

[jggimi]

Glad you got things working!

(We've all done this, by the way. Anyone who hasn't inadvertently misconfigured a network hasn't designed one.)

[wbe]

Here is a follow-up question. I have a network like the one below.

               .-----------------.     [Network A]
               '                 '    /
           Internet - [VPN] - [Router]
                                      \
                                       [Network B]

Clients connect to the public IP of the VPN, which then redirects the traffic to the router, which in turn redirects it to a server on network A. When the server responds, the traffic takes the default route, which is directly through the internet. Clearly that does not work.

The behavior I'm looking for is, regarding traffic from the server; if the destination is not in network B (local clients), then block the traffic from using the default gateway and force it out through the VPN which is the same way it came in. I don't know how to do that. Pointers? (Local clients on network B can work with server(s) on network A without issues.)

[jggimi]

It should be possible to provision the VPN to use NAT. If so, this would likely be the simplest operational solution. Otherwise, perhaps PF's reply-to or route-to would solve the problem.

[wbe]

Forgot to mention that the server needs the client IP, which rules out the NAT solution.

Below is a rule that I have tried; the return traffic never shows up on enc0.

pass in log on enc0 proto tcp from any to $router port $port \
    rdr-to $server port $port reply-to enc0

$router corresponds to the IP of enc0.

[jggimi]

See the enc(4) man page regarding the 3 requirements for using it with PF. You may need if-bound, and you may also need to match an existing flow.

[wbe]

Setting up a matching flow works for external access to the server. Local access from other internal networks is gone, but I can probably rewrite the flows or create bypass rules. I would much rather try to keep the entire setup within /etc/pf.conf though.

From enc(4):

Finally, the use of translation rules to map and redirect network traffic requires some care. Packets destined to be IPsec processed are seen by the filter/translation engine twice, both before and after being IPsec processed. If a packet's translated address on the way back fails to match an existing IPsec flow, from the translated address to the original source address, it will be discarded by the filter. It is best to avoid this situation where possible, though a flow may be explicitly created to work around it.

It seems the only solution is to set up a flow, and work from there. nat-to cannot be used before the IPsec flow matching is done if I understand it correctly.

[wbe]

The way I solved it is that I set up a bypass rule in /etc/ipsec.conf:

flow esp out from $server to $networkb type bypass

This way clients connecting from network B can access the server, too.

Thanks for the pointer to the enc(4) man page. I think I have an expectation that the man pages are not that informative (coming from other operating systems), but I'm really very pleasantly surprised by the information I can find in them.

[jggimi]

I would never have found that.

Congratulations on getting the issue resolved!