DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 19th March 2010
SchippStrich SchippStrich is offline
New User
 
Join Date: Mar 2010
Location: /dev/null
Posts: 7
Default pf rdr problem

I've been trying to solve this problem for about two weeks now and can't seem to figure it out.

I'm trying to do redirection to ingress traffic hitting my external interface(WAN address) to a server on my LAN.
xl1 - is the external int
xl0 - is the internal int and the gateway for the "server". Private addressing (192.168.1.*)
fxp0 - is another internal interface for my wireless clients. Priv addressing (192.168.2.*)
The server is 192.168.1.20 port 666
I can't seem to access the particular service on port 666 from outside my network or from within my network on fxp0 but I can access it from being on the xl0 network which is the same network that the server is on (Addresses in the 192.168.1.* network)

Code:
set require-order no
set skip on lo
set block-policy drop
scrub in on xl1 all
# NAT/filter rules and anchors for ftp-proxy(8)
nat on xl1 from 192.168.1.0/24 to any -> (xl1)
nat on xl1 from 192.168.2.0/24 to any -> (xl1)
##Redirect traffic on xl1 to 192.168.1.20 with port 666 in the TCP segment#
rdr pass on xl1 proto tcp from any to xl1 port 666 \
-> 192.168.1.20
##I thought this would allow traffic back out the external int to the WAN###
pass proto tcp from 192.168.1.20 to any port 666 \
flags S/SA keep state
###I thought this would allow access from my internal networks###
pass proto tcp from any to any port 666

# NAT/filter rules and anchors for relayd(8)
#rdr-anchor "relayd/*"
#ftp redirection/forwarding
#anchor "relayd/*"
## I had a DNS server running at one point##
block in on xl1 proto tcp from any to any port 53
block out on xl1 proto tcp from any to any port 53
block in on xl1 proto { tcp, udp } from any to any port { 136, 137, 138, 139, 445}
block out on xl1 proto { tcp, udp } from any to any port { 136, 137, 138, 139, 445}
block in on xl1 proto { tcp, udp } from any to 192.168.1.5
block out on xl1 proto { tcp, udp} from 192.168.1.5 to any
block inet proto icmp all icmp-type timerep
block inet proto icmp all icmp-type timereq
Reply With Quote
  #2   (View Single Post)  
Old 19th March 2010
DutchDaemon's Avatar
DutchDaemon DutchDaemon is offline
Real Name: Ben
Spam Refugee
 
Join Date: Jul 2008
Location: Rotterdam, The Netherlands
Posts: 336
Default

You have to 'pass out' that redirected connection on xl0 as well. The 'rdr pass' only takes care of allowing the connection in on xl1.
Reply With Quote
  #3   (View Single Post)  
Old 19th March 2010
SchippStrich SchippStrich is offline
New User
 
Join Date: Mar 2010
Location: /dev/null
Posts: 7
Default

Code:
pass out proto tcp from xl0 to any port 666
I'm not sure if that is what you meant but it still doesn't work.
Reply With Quote
  #4   (View Single Post)  
Old 19th March 2010
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,975
Default

The pass keyword on a redirection rule does go through stateful processing (keep state), but translation occurs before filtering is applied. The filter rules apply to translated packets.

l saw at least one problem with SchippStrich's latest "pass out" rule:
  • The "from" address is the xl0 NIC, but the from address will be on the Internet, not the originating IP address of xl0. This rule will never match.
I recommend following the guidance in the PF User's Guide -- in the Traffic Redirection chapter, there is a section called Redirection and Packet Filtering, showing the packets before and after translation.

Debugging is certainly warranted, using tcpdump(8), pflog(4), pflogd(8). Without this, SchippStrich will continue guessing.
Reply With Quote
  #5   (View Single Post)  
Old 19th March 2010
DutchDaemon's Avatar
DutchDaemon DutchDaemon is offline
Real Name: Ben
Spam Refugee
 
Join Date: Jul 2008
Location: Rotterdam, The Netherlands
Posts: 336
Default

Quote:
Originally Posted by SchippStrich View Post
Code:
pass out proto tcp from xl0 to any port 666
I'm not sure if that is what you meant but it still doesn't work.
No.

You need this 'combo':

Code:
rdr pass on xl1 inet proto tcp from any to xl1 port 666 -> 192.168.1.20
pass out quick on xl0 inet proto tcp from any to 192.168.1.20 port 666
Note that the 'any' in these rules is the external IP address, so suppose you allow the connection only to e.g. public IP address 123.123.123.123, 'any' gets changed to '123.123.123.123' in both rules.
Reply With Quote
  #6   (View Single Post)  
Old 19th March 2010
SchippStrich SchippStrich is offline
New User
 
Join Date: Mar 2010
Location: /dev/null
Posts: 7
Default

Here are my updated rules.
It's still not working though.
Code:
nat on xl1 from 192.168.1.0/24 to any -> (xl1)
nat on xl1 from 192.168.2.0/24 to any -> (xl1)
rdr pass on xl1 inet proto tcp from any to xl1 port 666 \
-> 192.168.1.20
pass proto tcp from 192.168.1.20 to any port 666 \
flags S/SA keep state
pass out quick on xl0 inet proto tcp from any to 192.168.1.20 port 666
I have printed the PF User guide and read it multiple times. I've also looked at past threads and the list Daemon Forums PF guide list sticky thread.

I was going to resort to using pflog but I figured I would come here first.
Reply With Quote
  #7   (View Single Post)  
Old 20th March 2010
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,125
Default

Although I could not test, the following snippet using tags. should do it.
Code:
EXT = xl0
INT = rl0

nat on $EXT from 192.168.1.0/24 to any -> ($EXT)
nat on $EXT from 192.168.2.0/24 to any -> ($EXT)

rdr on $EXT inet proto tcp to $EXT port 666 tag RDR_OK  -> 192.168.1.20 

block log all

pass in quick on $EXT tagged RDR_OK
pass out quick on $INT tagged RDR_OK
On my test machine (just a syntax test), this will expand to
Code:
# pfctl -vvnf labels-rdr  
EXT = "xl0"
INT = "rl0"
@0 nat on xl0 inet from 192.168.1.0/24 to any -> (xl0) round-robin
@1 nat on xl0 inet from 192.168.2.0/24 to any -> (xl0) round-robin
@2 rdr on xl0 inet proto tcp from any to 10.0.0.200 port = 666 tag RDR_OK -> 192.168.1.20
@0 block drop log all
@1 pass in quick on xl0 all flags S/SA keep state tagged RDR_OK
@2 pass out quick on rl0 all flags S/SA keep state tagged RDR_OK
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
  #8   (View Single Post)  
Old 20th March 2010
SchippStrich SchippStrich is offline
New User
 
Join Date: Mar 2010
Location: /dev/null
Posts: 7
Default

J65nko, I just tried your solution and it also failed to work.

I do appreciate everyones help.
Reply With Quote
  #9   (View Single Post)  
Old 20th March 2010
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,975
Default

Stop experimenting. Find out what's actually happening.

Here's a three step diagnostic:

Step 1: Make sure IP forwarding is enabled (I know, I know, it already is, but check anyway, just to be sure, mmkay?).

If it is not enabled, excecute facepalm. If it is enabled, proceed to Step 2.

Step 2: Re-read the section of the PF user's guide, under "Redirection and Reflection".

If the warning, "...But when the redirection rule is tested from a client on the LAN, it doesn't work...." applies to your situation, execute facepalm. If it does not apply, and you are actually testing redirection from a remote facility, proceed to Step 3.

Step 3: Use tcpdump and see what's actually happening.

Example: What block rules are matching?

# tcpdump -neti pflog0 action block

I like to log my pass rules too, so I can see what pass rules match, also.
Reply With Quote
Old 20th March 2010
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,125
Default

Code:
          INTERNET
              |
              |
--------------|---------------------
           external           
             xl1             
        xxx.xxx.xx.xx      
                     
                      
  192.168.1.1    192.168.2.1     
      xl0           fxp0 
    internal     wireless    
-------|-------------|-------------
       |             |
       |            /|\                 \ | /
       |           / | \                 \|/
    switch                                |
  internal Lan                     -------|--------
  192.168.1.0/24                   wireless client
          \                         192.168.2.22
           \                       ---------------
            \
             \
              \
       --------\-------------
            server
       192.168.1.20 port 666
       ----------------------
Quote:
I'm trying to do redirection to ingress traffic hitting my external interface(WAN address) to a server on my LAN.
xl1 - is the external int
xl0 - is the internal int and the gateway for the "server". Private addressing (192.168.1.*)
fxp0 - is another internal interface for my wireless clients. Priv addressing (192.168.2.*)
The server is 192.168.1.20 port 666
I can't seem to access the particular service on port 666 from outside my network or from within my network on fxp0 but I can access it from being on the xl0 network which is the same network that the server is on (Addresses in the 192.168.1.* network)
The rules I gave take care of traffic incoming from the internet to your external/egress interface.

Ingres traffic (192.168.1.0/24 and 192.168.2.0/24) should be able to access your 192.168.1.20 server with normal routing.

And please read http://www.openbsd.dk/faq/pf/rdr.html#reflect that the wireless clients have to either use the 192.168.1.20 address, or that you have to create a split horizon DNS
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
Old 20th March 2010
SchippStrich SchippStrich is offline
New User
 
Join Date: Mar 2010
Location: /dev/null
Posts: 7
Default

I have tested each method from an external network.
I've been at school using ssh to modify pf.conf.

I'll try using pflog and tcpdump to see what's going on.

Quote:
Originally Posted by J65nko View Post
Ingres traffic (192.168.1.0/24 and 192.168.2.0/24) should be able to access your 192.168.1.20 server with normal routing.
If the two internal interface are attached to the box running PF with my default deny policy, wouldn't traffic be blocked on all interfaces unless explicitly mentioned to pf?
That's how I understand it.

Last edited by ocicat; 20th March 2010 at 05:17 AM. Reason: When quoting, use [QUOTE] & [/QUOTE] tags, not [CODE] & [/CODE] tags.
Reply With Quote
Old 21st March 2010
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,125
Default

Quote:
Originally Posted by SchippStrich View Post
If the two internal interface are attached to the box running PF with my default deny policy, wouldn't traffic be blocked on all interfaces unless explicitly mentioned to pf?
That's how I understand it.
That is correct, with a default deny policy you have to explictly define rules which allow traffic between192.168.1.0/24 and 192.168.2.0/24.

But you also need to define default gateways.
  • The boxes of the 192.168.1.0/24 network need to define192.168.1.1 as the default gateway.

    This means that all traffic with a non-192.168.1.0 destination needs to directed to 192.168.1.1.
  • The wireless clients on 192.168.2.0/24 need to be told that 192.168.2.1 is the default gateway.

    Here the non-192.168.2.0 packets need to be sent to 192.168.2.1

You can set the default gateway on OpenBSD machines without rebooting with
Code:
 # route add default 192.168.1.1
For a permanent, reboot surviving setting use
Code:
# echo 192.168.1.1 >/etc/mygate
Or configure DHCP on the OBSD router to do this.
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
Old 22nd March 2010
SchippStrich SchippStrich is offline
New User
 
Join Date: Mar 2010
Location: /dev/null
Posts: 7
Default

Routing is fine, I've had this network running for over a year. I can reach anyone and they can reach me. I've done static routes plenty of times with route. I also have had dhcpd set up and working well for quite sometime.
My problem is strictly pf. I've never had a problem with pf until I tried using redirection which seems to be kicking my ass. A lot of examples I find for solving rdr problems are completely different, not being consistent.

I will try and read the redirection section of the user guide again sometime this weekend. Hopefully I've missed something... Every time I modify pf.conf hoping to solve the problem, I do a nmap scan and receive a TCP RST (port is closed).
My SYN's are getting stopped in there tracks. I will double check to see if my server is the one sending the RST, but I'm pretty sure I have /etc/allow and /deny set properly.

I'll get back with you guys in a bit, sorry it's been a busy week.
Reply With Quote
Old 30th March 2010
SchippStrich SchippStrich is offline
New User
 
Join Date: Mar 2010
Location: /dev/null
Posts: 7
Default

Quote:
My SYN's are getting stopped in there tracks.
Technically, they're not getting stopped but you know what I mean. No SYN+ACK return. I just thought I would clarify in case someone is like "What the hell is he saying"
Quote:
but I'm pretty sure I have /etc/allow and /deny set properly.
This is setup correctly, I just checked.

I'm going to try to get the xl0 and the fxp0 networks to allow the TCP segments of destination port 666 tomorrow to solve the first problem which I think I can do . As for as the rdr problem, I'm still stumped. I've been up for 32 hours so after I get a good nights rest I'll report back tomorrow. I haven't had time for the manual yet though, I'll get to it.
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
Boot problem. Geometry problem? gulanito FreeBSD Installation and Upgrading 0 3rd July 2009 03:03 AM


All times are GMT. The time now is 08:37 AM.


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