Re: RDR for internal machine
On Mon, Mar 31, 2003 at 10:53:09AM -0600, Darley Ware wrote: 1. I have webserver on the internal LAN which listens on port 8000. I can view the webserver internally by IP and by name (using LMHOST records). I have not however been able to access the internal webserver from the outside. I saw a post the weekend about name based virtualhosting on web servers. This does not seem to apply to me as I have the server setup to respond to IP and have no virtualdomains configured. So I guess my question is do I have my redirect setup correctly, and if so where lies the problem? And you permit packets on $internal_if going to internal web server? rdr rules are not enough. Btw, filtering happens _after_ rdr, so you have to permit packets after the translation. What does tcpdump on webserver shows? Do you see any packets? 2. (and this one really is not that important) I can not seem to get a response to ICMP to outside addresses. I can ping both directions from the firewall and I believe my pings are getting out, but the responses to not return to the internal clients. Lemme get this right. You ping hosts outside your LANs and don't get responses back to the clients, but from the firewall itself, it works? Check your rules. If you 'block all on $inside_if' or something, you have to explicitly pass in/out icmp traffic on $inside_if. Again, tcpdump output could be nice. // haver
Re: NEWBIE: alias or vlan?
On Sunday, Mar 30, 2003, at 15:04 US/Pacific, s c o t t wrote: System: OpenBSD 3.2 +latest security patches applied. Dual Linksys TX100 Nics. One connected to DSL modem, one connected to LAN. PF configured to NAT my internal network. My nextdoor neighbor gave me a Cisco 350 wireless access point so he could hijack some of my bandwidth. I agreed but want to maintain control. Here are my questions: 1) Initially I have thought about setting up a vlan on my internal Nic for the network I will assign to the wireless segment. Is this preferred over assigning an alias with ifconfig? Considering the gear, I would personally go with a VLAN. It makes for a clean separation of networks on the same physical interface, which is what you're after. 2) To restrict things a bit I was going to cfg the WAP to grab an IP from DHCP and I was going to configure DCHP for this segment to be limited to two addresses (with something equivalent to a 255.255.255.254 subnet mask). 255.255.255.252 to allow for IP network and broadcast space. 3) I would like to augment my pf ruleset to block traffic from the wireless segment to the wired (and maybe vice versa0. It seems, at least conceptually, that this will be easier to do if I go the VLAN route vs. adding an alias but again I really don't know. Any thoughts? I agree. 4) I assume with either case I will need to extend my NAT rule to NAT this new traffic from the VLAN (or alias)? Yes. 5) Lastly it seems like the pf man page and HOWTO use the notation /N following an IP address to indicate which octets matter (i.e. 192.168.1.0/24 means the last three octets). Is this correct? That is known as CIDR notation. The N refers to the number of significant bits for the mask. See this page for a decent explanation, just ignore the IRC-specific stuff: http://ircd-hybrid.org/docs/CIDR.txt So, If hypothetically I defined some things in my pf.conf: EXT=ep1 INT=ep0 LAN=192.168.1.0/24 VLAN=192.168.2.0/24 Could I stipulate that my VLAN network address was 192.168.2.10 with a netmask of 255.255.255.254 and would the similar notation, VLAN=192.168.2.10/24 still be valid (for the two hosts 192.168.2.10 and .11? Not quite. As I mentioned above, that space needs to be expanded to 4 addresses to allow for IP broadcast. For the netmask to work, it will need to be on an address boundary divisible by 4. So, something like 192.168.2.8/30, making .9 and .10 your usable addresses.
Re: RDR for internal machine
On Monday, Mar 31, 2003, at 08:53 US/Pacific, Darley Ware wrote:
1. I have webserver on the internal LAN which listens on port 8000.
I can
view the webserver internally by IP and by name (using LMHOST
records). I
have not however been able to access the internal webserver from the
outside. I saw a post the weekend about name based virtualhosting on
web
servers. This does not seem to apply to me as I have the server setup
to
respond to IP and have no virtualdomains configured. So I guess my
question
is do I have my redirect setup correctly, and if so where lies the
problem?
2. (and this one really is not that important) I can not seem to get
a
response to ICMP to outside addresses. I can ping both directions
from the
firewall and I believe my pings are getting out, but the responses to
not
return to the internal clients.
As the others commented, tcpdump logs would have been useful. You can
also apply tcpdump to pflog0 to see what pf is logging. Make sure to
use tcpdump's -e switch there.
Rule comments inline:
# OpenBSD: pf.conf,v 1.6 2002/06/27 07:00:43 fgsch Exp $
#
#
###
--
### MACROS - define interfaces: internet, intranet, wireless net
###
if_ext = dc0
if_int = fxp0
if_wir = an0
INT_Net=192.168.XX.XX/27
WIFI_Net=192.168.YY.YY/27
bad_ports = 69,135,137,138,139,445,524,548,1433,6000,31337,666,12345
no_route = { 127.0.0.1/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8, \
255.255.255.255/32 }
###
--
### Optimization
###
#set optimization aggressive
#set timeout tcp.established 3600
#set timeout { tcp.opening 30, tcp.closing 120 }
#set limit { states 2, frags 5000 }
###
--
### statistics logging on external interface
###
set loginterface $if_ext
set loginterface $if_wir
###
--
### NAT Gateways
###
nat on $if_ext from $INT_Net to any - $if_ext
nat on $if_ext from $WIFI_Net to any - $if_ext
# Redirect outside ports to internal servers
rdr on dc0 proto tcp from any to (dc0) port 8000 - 192.168.XX.71 port
8000
rdr on dc0 proto udp from any to (dc0) port 8000 - 192.168.XX.71 port
8000
###
--
### DEFAULT RULES
###
# INCOMING DEFAULT: block and normalize all
#scrub in on all
block in log all
# OUTGOING DEFAULT: block all
block out log all
# SPECIAL IMMEDIATE BLOCKS:
# block bad ports and external broadcasts
block in quick proto { udp,tcp } from any to any port { = $bad_ports }
block in quick on $if_ext from any to 255.255.255.255
block in quick on $if_wir from any to 255.255.255.255
# block weird tcp packets on WAN:
block in quick on $if_ext inet proto tcp from any to any flags FUP/FUP
block in quick on $if_ext inet proto tcp from any to any flags SF/SFRA
block in quick on $if_ext inet proto tcp from any to any flags /SFRA
# block weird tcp packets on WiFi:
block in quick on $if_wir inet proto tcp from any to any flags FUP/FUP
block in quick on $if_wir inet proto tcp from any to any flags SF/SFRA
block in quick on $if_wir inet proto tcp from any to any flags /SFRA
# don't allow anyone to spoof non-routeable addresses
block in quick on $if_ext from $no_route to any
block out quick on $if_ext from any to $no_route
###
--
### LOOPBACK
###
pass in quick on lo0 all
pass out quick on lo0 all
These are overridden by the $bad_ports block rule above. Not likely
an issue, but something to be aware of.
###
--
### EXTERNAL INTERFACE
###
# INCOMING: accept ssh
pass in quick on $if_ext proto tcp from any to $if_ext/24 port = 22
flags
S/SA keep state
pass in quick on $if_ext proto tcp from any to $if_ext/24 port = 8000
No keep state. This is a problem because...
# INCOMING DEFAULT: block all incoming
# OUTGOING: block non nated packets, pass the others
block out quick on $if_ext from !$if_ext/24 to any
pass out quick on $if_ext proto tcp from $if_ext/24 to any flags S/SA
keep
state
...this rule cannot pick up SA/SA, which will be the outbound response
to
the inbound S/SA for the webserver.
pass out quick on $if_ext proto { udp } from $if_ext/24 to any keep
state
# ICMP: ping
# remove next to block ping from Internet
pass in on $if_ext inet proto icmp all icmp-type 8 code 0 keep state
pass out on $if_ext inet proto icmp all icmp-type 8 code 0 keep state
# OUTGOING DEFAULT: block all outgoing
###
--
### INTERNAL INTERFACE
###
# INCOMING: traffic to fw, accept ssh dhcp only, block the rest
pass in quick on $if_int proto tcp from $if_int/27 to $if_int/27 port
= 22
flags S/SA keep state
pass in quick on $if_int
Re: RDR for internal machine
Zitiere Darley Ware [EMAIL PROTECTED]: 1. I have webserver on the internal LAN which listens on port 8000. I can view the webserver internally by IP and by name (using LMHOST records). I have not however been able to access the internal webserver from the outside. I saw a post the weekend about name based virtualhosting on web servers. This does not seem to apply to me as I have the server setup to respond to IP and have no virtualdomains configured. So I guess my question is do I have my redirect setup correctly, and if so where lies the problem? No, you're blocking the redirected request. Redirection happens before the evaluation of pass/block rules. So rdr on dc0 proto tcp from any to (dc0) port 8000 - 192.168.XX.71 port 8000 redirects the request to 192.168.xx.71:8000 on dc0, and block in log all pass in quick on $if_ext proto tcp from any to $if_ext/24 port = 8000 does not let it pass, because the destination for the request is not $if_ext but 192.168.XX.71. So if you change it to pass in quick on $if_ext proto tcp from any to 192.168.XX.71 port = 8000 keep state it should work. 2. (and this one really is not that important) I can not seem to get a response to ICMP to outside addresses. I can ping both directions from the firewall and I believe my pings are getting out, but the responses to not return to the internal clients. If i understand you correctly, pinging works from the firewall in all directions (inwards and outwards), but not from internal clients to servers outside the firewall. Add pass in on $if_int inet proto icmp all icmp-type 8 code 0 keep state to your rules for your internal interface, and all should be fine. You're blocking the pings on your internal interface, if i'm not mistaken. Thanks, Darley Hope to have helped, Clemens
OpenBSD 3.2, NAT PF - Strange Error.
Title: OpenBSD 3.2, NAT PF - Strange Error. Good day to all. I am getting a strange error message when trying to use ALIASes for my bsd box and am hoping someone (with better eyes or brains) can assist. Specifically the message is: stuff here... then - translation adress expands to multiple IPs of this address family (more...) SYNOPSIS: 1) Running OpenBSD 3.2. 2) /etc/hostname.ne3 file looks like so: inet y.y.y.y.250 255.255.252.0 NONE #inet alias z.z.z.251 255.255.255.255 z.z.z.255 # six more addresses - I currently have them commented out to eliminate the error message, 3) /etc/nat.conf # nat section: packets going out through ne3 with source address internal network/24 get # translated as coming from x.x.x.x. nat on ne3 inet from x.x.x.0/24 to any - ne3 The bizarre part (at least for me at this point) is that I've done this with 2.7, 2.9 and 3.0 - no harm, no fowl. If I comment out the ALIASes, all works as expected. I would greatly appreciate any assistance that I can get. Thanks... Richard Gutery
Re: OpenBSD 3.2, NAT PF - Strange Error.
On Mon, Mar 31, 2003 at 03:20:16PM -0700, Richard Gutery wrote: stuff here... then - translation adress expands to multiple IPs of this address family (more...) The bizarre part (at least for me at this point) is that I've done this with 2.7, 2.9 and 3.0 - no harm, no fowl. Prior versions silently picked one of the aliases more or less arbitrarily, while the new version requires you to decide which alias to use. Change your rule to nat on ne3 inet from x.x.x.0/24 to any - y.y.y.250 so it's clear which address should be used. Daniel
RE: OpenBSD 3.2, NAT PF - Strange Error.
Title: RE: OpenBSD 3.2, NAT PF - Strange Error. Thanks Daniel, that fixed it up real goot. I suppose that I could NAT all the addresses, but that's for a later date. Richard ---BeginMessage--- Title: Re: OpenBSD 3.2, NAT PF - Strange Error. On Mon, Mar 31, 2003 at 03:20:16PM -0700, Richard Gutery wrote: stuff here... then - translation adress expands to multiple IPs of this address family (more...) The bizarre part (at least for me at this point) is that I've done this with 2.7, 2.9 and 3.0 - no harm, no fowl. Prior versions silently picked one of the aliases more or less arbitrarily, while the new version requires you to decide which alias to use. Change your rule to nat on ne3 inet from x.x.x.0/24 to any - y.y.y.250 so it's clear which address should be used. Daniel ---End Message--- Richard Gutery.vcf Description: Binary data
OpenBSD 3.2, NAT PF - Strange Error.
Title: OpenBSD 3.2, NAT PF - Strange Error. Oops, spoke too soon. Seems it worked, but alas, when I tried to browse other sites and review some other mailers, I constantly got Page not found errors. So it appears something else is amiss. However, I do have something to go on now. TX, again, Cheers. Richard
Re: grouped tcp flags
On 01/04/2003, jared r r spiegel [EMAIL PROTECTED] wrote To [EMAIL PROTECTED]:
will
the following work? Does pf syntax allow this?
BadTCPFlags={ FUP, FUP/FUP, SF/SFRA, /SFRA, F/SFRA, U/SFRAU, P, \
FS/FS, FSRPAU, /FSRPAU }
block in quick proto tcp all flags $BadTCPFlags
no (geeez!).. dont overdo this flag shit, mmkay?
flags = flags ( flag-set / flag-set | / flag-set )
flag-set = [ F ] [ S ] [ R ] [ P ] [ A ] [ U ] [ E ] [ W ]
this is wrong.. who wrote that shit? :)
flags = [ flag-set ] / flag-set
(Daniel, ok? :) )
//pb
further reply-to strangeness
As I mentioned on the list a few days ago I have been having some
trouble with reply-to. In particular it seems to be generating a bad tc
checksum for the return packet. Since then I have rebuilt kernel and
world to source checked out this morning (3/31) and it seems to properly
return route pings, but still fails on the TCP with bad checksums. I
have put a more full TCP packet trace from the client machine below in
case it sparks something in anyone.
Thank you for any help.
-David Powers
17:53:16.652413 xxx.xxx.xxx.xxx.port yyy.yyy.yyy.yyy.ssh: S [tcp sum ok]
1807604332:1807604332(0) win 57344 mss 1460,nop,wscale 0,nop,nop,timestamp 2018840 0
(DF) (ttl 64, id 26021, len 60)
0x 4500 003c 65a5 4000 4006 84ab cf63 7353E..[EMAIL PROTECTED]@csS
0x0010 d8e0 34d4 0a2a 0016 6bbd da6c ..4..*..k..l
0x0020 a002 e000 fbfa 0204 05b4 0103 0300
0x0030 0101 080a 001e ce18
17:53:16.677889 yyy.yyy.yyy.yyy.ssh xxx.xxx.xxx.xxx.port: S [bad tcp cksum 53a0!]
3475200739:3475200739(0) ack 1807604333 win 17376 mss 1460,nop,wscale 0,nop,nop,timestamp
21658571 2018840 (DF) (ttl 58, id 42684, len 60)
0x 4500 003c a6bc 4000 3a06 4994 d8e0 34d4E..[EMAIL PROTECTED]:.I...4.
0x0010 cf63 7353 0016 0a2a cf23 5ae3 6bbd da6d.csS...*.#Z.k..m
0x0020 a012 43e0 509a 0204 05b4 0103 0300..C.P...
0x0030 0101 080a 014a 7bcb 001e ce18 .J{.
17:53:19.645037 xxx.xxx.xxx.xxx.port yyy.yyy.yyy.yyy.ssh: S [tcp sum ok]
1807604332:1807604332(0) win 57344 mss 1460,nop,wscale 0,nop,nop,timestamp 2019140 0
(DF) (ttl 64, id 57581, len 60)
0x 4500 003c e0ed 4000 4006 0963 cf63 7353E..[EMAIL PROTECTED]@..c.csS
0x0010 d8e0 34d4 0a2a 0016 6bbd da6c ..4..*..k..l
0x0020 a002 e000 face 0204 05b4 0103 0300
0x0030 0101 080a 001e cf44 ...D
17:53:19.670317 yyy.yyy.yyy.yyy.ssh xxx.xxx.xxx.xxx.port: S [bad tcp cksum 219f!]
3475200739:3475200739(0) ack 1807604333 win 17376 mss 1460,nop,wscale 0,nop,nop,timestamp
21658577 2019140 (DF) (ttl 58, id 65290, len 60)
0x 4500 003c ff0a 4000 3a06 f145 d8e0 34d4E..[EMAIL PROTECTED]:..E..4.
0x0010 cf63 7353 0016 0a2a cf23 5ae3 6bbd da6d.csS...*.#Z.k..m
0x0020 a012 43e0 509a 0204 05b4 0103 0300..C.P...
0x0030 0101 080a 014a 7bd1 001e cf44 .J{D
17:53:22.845106 xxx.xxx.xxx.xxx.port yyy.yyy.yyy.yyy.ssh: S [tcp sum ok]
1807604332:1807604332(0) win 57344 mss 1460,nop,wscale 0,nop,nop,timestamp 2019460 0
(DF) (ttl 64, id 21241, len 60)
0x 4500 003c 52f9 4000 4006 9757 cf63 7353E..[EMAIL PROTECTED]@..W.csS
0x0010 d8e0 34d4 0a2a 0016 6bbd da6c ..4..*..k..l
0x0020 a002 e000 f98e 0204 05b4 0103 0300
0x0030 0101 080a 001e d084
17:53:23.497186 yyy.yyy.yyy.yyy.ssh xxx.xxx.xxx.xxx.port: S [bad tcp cksum d99d!]
3475200739:3475200739(0) ack 1807604333 win 17376 mss 1460,nop,wscale 0,nop,nop,timestamp
21658585 2019460 (DF) (ttl 58, id 63080, len 60)
0x 4500 003c f668 4000 3a06 f9e7 d8e0 34d4E..[EMAIL PROTECTED]:.4.
0x0010 cf63 7353 0016 0a2a cf23 5ae3 6bbd da6d.csS...*.#Z.k..m
0x0020 a012 43e0 509a 0204 05b4 0103 0300..C.P...
0x0030 0101 080a 014a 7bd9 001e d084 .J{.
17:53:26.045343 xxx.xxx.xxx.xxx.port yyy.yyy.yyy.yyy.ssh: S [tcp sum ok]
1807604332:1807604332(0) win 57344 mss 1460 (DF) (ttl 64, id 35829, len 44)
0x 4500 002c 8bf5 4000 4006 5e6b cf63 7353E..,[EMAIL PROTECTED]@.^k.csS
0x0010 d8e0 34d4 0a2a 0016 6bbd da6c ..4..*..k..l
0x0020 6002 e000 1750 0204 05b4 `P..
17:53:26.074621 yyy.yyy.yyy.yyy.ssh xxx.xxx.xxx.xxx.port: S [bad tcp cksum d49d!]
3475200739:3475200739(0) ack 1807604333 win 17376 mss 1460,nop,wscale 0,nop,nop,timestamp
21658590 2019460 (DF) (ttl 58, id 49424, len 60)
0x 4500 003c c110 4000 3a06 2f40 d8e0 34d4E..[EMAIL PROTECTED]:./@..4.
0x0010 cf63 7353 0016 0a2a cf23 5ae3 6bbd da6d.csS...*.#Z.k..m
0x0020 a012 43e0 509a 0204 05b4 0103 0300..C.P...
0x0030 0101 080a 014a 7bde 001e d084 .J{.
17:53:29.245529 xxx.xxx.xxx.xxx.port yyy.yyy.yyy.yyy.ssh: S [tcp sum ok]
1807604332:1807604332(0) win 57344 mss 1460 (DF) (ttl 64, id 12758, len 44)
0x 4500 002c 31d6 4000 4006 b88a cf63 7353E..,[EMAIL PROTECTED]@csS
0x0010 d8e0 34d4 0a2a 0016 6bbd da6c ..4..*..k..l
0x0020 6002 e000 1750 0204 05b4 `P..
17:53:29.270544 yyy.yyy.yyy.yyy.ssh xxx.xxx.xxx.xxx.port: S [bad tcp cksum ce9d!]
3475200739:3475200739(0) ack 1807604333 win 17376 mss 1460,nop,wscale
