DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 12th February 2019
wbe wbe is offline
New User
 
Join Date: Aug 2018
Posts: 7
Default Tricky inbound redirect with pf

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.)
Reply With Quote
  #2   (View Single Post)  
Old 12th February 2019
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

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.
Reply With Quote
  #3   (View Single Post)  
Old 12th February 2019
wbe wbe is offline
New User
 
Join Date: Aug 2018
Posts: 7
Default

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.

Code:
pass in proto tcp from any to 192.168.0.1 port 443 rdr-to 192.168.0.2
Reply With Quote
  #4   (View Single Post)  
Old 12th February 2019
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

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):
Quote:
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.

Last edited by jggimi; 12th February 2019 at 01:56 PM. Reason: clarity, and alias is also discussed in hostname.if(5)
Reply With Quote
  #5   (View Single Post)  
Old 12th February 2019
wbe wbe is offline
New User
 
Join Date: Aug 2018
Posts: 7
Default

Quote:
Originally Posted by jggimi View Post
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.

Quote:
Originally Posted by jggimi View Post
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.
Reply With Quote
  #6   (View Single Post)  
Old 12th February 2019
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

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.)
Reply With Quote
  #7   (View Single Post)  
Old 14th February 2019
wbe wbe is offline
New User
 
Join Date: Aug 2018
Posts: 7
Default

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

Code:
               .-----------------.     [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.)
Reply With Quote
  #8   (View Single Post)  
Old 15th February 2019
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

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.
Reply With Quote
  #9   (View Single Post)  
Old 15th February 2019
wbe wbe is offline
New User
 
Join Date: Aug 2018
Posts: 7
Default

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.

Code:
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.
Reply With Quote
Old 15th February 2019
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

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.
Reply With Quote
Old 15th February 2019
wbe wbe is offline
New User
 
Join Date: Aug 2018
Posts: 7
Default

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):

Quote:
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.
Reply With Quote
Old 15th February 2019
wbe wbe is offline
New User
 
Join Date: Aug 2018
Posts: 7
Default

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

Code:
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.

Last edited by wbe; 15th February 2019 at 01:35 PM.
Reply With Quote
Old 15th February 2019
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

I would never have found that.

Congratulations on getting the issue resolved!
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Redirect kernel messages to another vt? darktrym NetBSD General 2 16th October 2016 11:52 AM
Cannot redirect oidentd port 113 to jail bryn1u FreeBSD General 2 21st June 2014 01:32 PM
redirect outgoing http petter OpenBSD Security 8 25th March 2013 04:56 PM
VNC and sound redirect DNAeon FreeBSD Ports and Packages 2 16th September 2009 07:52 PM
Tricky Partition Issues disappearedng FreeBSD General 6 7th July 2008 11:22 PM


All times are GMT. The time now is 01:34 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick