Using OpenBSD as a router
I have been googling this issue today and I am finding that I don't quite know enough about what I am doing, and that the terms I am searching for are not returning the results I want. I have need of using OpenBSD as a router temporarily. I have four interfaces. bge0 - my primary interface that will be facing my ISP's border router bge1: +vlan1 - Segment for my subnet1 +vlan2 - Segment for my subnet2 +vlan3 - Segment for my subnet3 So I really only want routing functionality so I thought it was safe to do the following: - Set net.inet.ip.fordwarding=1 - Disabled PF This leaves me in a state where I can ping hosts in vlan1 from the network on bge0. But that's about it. I kinda don't know the right questions to ask here. Googling for routing leads to mostly sites dealing with adding static routes in OpenBSD. So from some of the reading on Faq6, I assumed that enabling forwarding would leave me with a system whereby packets entering any of the interfaces would be routed back out the correct interface for the subnet, or off onto the default gateway if no local subnet exists. But that assumption seems to be failing me. The faq also mentioned OpenBGPD and routed, but there doesn't appear to be any man page for routed and because my ISP is statically routing my subnets to me, apparently (according to them) I have no need of BGP. Could anyone offer any insight or advice on what I am doing wrong? Thanks! Geoff Sweet
Re: Using OpenBSD as a router
Oops, sorry I did mean to copy and paste that information in here as well, Bge0 is using a private static IP during testing of this of 192.168.16.223 Subnet1 : 66.150.173.0/26 Subnet2 : 66.150.7.0/25 Subnet3 : 72.2.215.0/24 The interfaces on the OpenBSD box are assigned static IP's at the top of each subnet, so 66.150.173.62, etc. Each host in the subnets are configured to use the OpenBSD interface as it's default gateway. From the 192.168.16 side I can ping a host 66.150.173.20 with no problems. But when I ping a host that is 66.150.7.25, via tcpdump I can see that the ICMP packet hits the 192.168.16 interface, and comes out the 66.150.7 interface, but any packet going back into the 66.150.7 interface just gets lost except for packets destined explicitly for the interface ip 66.150.173.126. In fact tcpdump shows nothing hitting the 66.150.7.126 interface at all if I am pinging a remote host. Output of ifconfig: # ifconfig lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 33200 priority: 0 groups: lo inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 bge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:22:19:d6:9c:04 priority: 0 groups: egress media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) status: active inet 192.168.16.223 netmask 0xff00 broadcast 192.168.16.255 inet6 fe80::222:19ff:fed6:9c04%bge0 prefixlen 64 scopeid 0x1 bge1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:22:19:d6:9c:05 priority: 0 media: Ethernet autoselect (1000baseT full-duplex) status: active inet6 fe80::222:19ff:fed6:9c05%bge1 prefixlen 64 scopeid 0x2 enc0: flags=0 priority: 0 groups: enc status: active vlan4091: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:22:19:d6:9c:05 priority: 0 vlan: 4091 priority: 0 parent interface: bge1 groups: vlan status: active inet6 fe80::222:19ff:fed6:9c05%vlan4091 prefixlen 64 scopeid 0x5 inet 66.150.7.126 netmask 0xff80 broadcast 66.150.7.127 vlan4092: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:22:19:d6:9c:05 priority: 0 vlan: 4092 priority: 0 parent interface: bge1 groups: vlan status: active inet6 fe80::222:19ff:fed6:9c05%vlan4092 prefixlen 64 scopeid 0x6 inet 72.5.215.254 netmask 0xff00 broadcast 72.5.215.255 vlan4093: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:22:19:d6:9c:05 priority: 0 vlan: 4093 priority: 0 parent interface: bge1 groups: vlan status: active inet6 fe80::222:19ff:fed6:9c05%vlan4093 prefixlen 64 scopeid 0x7 inet 66.150.173.62 netmask 0xffc0 broadcast 66.150.173.63 -Original Message- From: Ted Unangst [mailto:ted.unan...@gmail.com] Sent: Wednesday, December 01, 2010 2:52 PM To: Geoff Sweet Cc: misc@openbsd.org Subject: Re: Using OpenBSD as a router On Wed, Dec 1, 2010 at 5:41 PM, Geoff Sweet geoff.sw...@wemadeusa.com wrote: I have been googling this issue today and I am finding that I don't quite know enough about what I am doing, and that the terms I am searching for are not returning the results I want. I have need of using OpenBSD as a router temporarily. I have four interfaces. bge0 - my primary interface that will be facing my ISP's border router bge1: +vlan1 - Segment for my subnet1 +vlan2 - Segment for my subnet2 +vlan3 - Segment for my subnet3 So I really only want routing functionality so I thought it was safe to do the following: - Set net.inet.ip.fordwarding=1 - Disabled PF This leaves me in a state where I can ping hosts in vlan1 from the network on bge0. But that's about it. I kinda don't know the right questions to ask here. Googling for routing leads to mostly sites dealing with adding static routes in OpenBSD. So from some of the reading on Faq6, I assumed that enabling forwarding would leave me with a system whereby packets entering any of the interfaces would be routed back out the correct interface for the subnet, or off onto the default gateway if no local subnet exists. But that assumption seems to be failing me. The faq also mentioned OpenBGPD and routed, but there doesn't appear to be any man page for routed and because my ISP is statically routing my subnets to me, apparently (according to them) I have no need of BGP. Could anyone offer any insight or advice on what I am doing wrong? are the other computers configured to use the router as their gateway? more information about the networks and ips of the computers on either end, the output of ifconfig, and what exactly that's about it means would go a long way.
Re: Using OpenBSD as a router
Oh for the love of god... ok I am good. OpenBSD works pretty much as it should. Someone loaded damn switch ACL's onto this switch. Off to choke a junior admin to death. -Geoff -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Geoff Sweet Sent: Wednesday, December 01, 2010 3:48 PM To: misc@openbsd.org Subject: Re: Using OpenBSD as a router Oops, sorry I did mean to copy and paste that information in here as well, Bge0 is using a private static IP during testing of this of 192.168.16.223 Subnet1 : 66.150.173.0/26 Subnet2 : 66.150.7.0/25 Subnet3 : 72.2.215.0/24 The interfaces on the OpenBSD box are assigned static IP's at the top of each subnet, so 66.150.173.62, etc. Each host in the subnets are configured to use the OpenBSD interface as it's default gateway. From the 192.168.16 side I can ping a host 66.150.173.20 with no problems. But when I ping a host that is 66.150.7.25, via tcpdump I can see that the ICMP packet hits the 192.168.16 interface, and comes out the 66.150.7 interface, but any packet going back into the 66.150.7 interface just gets lost except for packets destined explicitly for the interface ip 66.150.173.126. In fact tcpdump shows nothing hitting the 66.150.7.126 interface at all if I am pinging a remote host. Output of ifconfig: # ifconfig lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 33200 priority: 0 groups: lo inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 bge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:22:19:d6:9c:04 priority: 0 groups: egress media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) status: active inet 192.168.16.223 netmask 0xff00 broadcast 192.168.16.255 inet6 fe80::222:19ff:fed6:9c04%bge0 prefixlen 64 scopeid 0x1 bge1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:22:19:d6:9c:05 priority: 0 media: Ethernet autoselect (1000baseT full-duplex) status: active inet6 fe80::222:19ff:fed6:9c05%bge1 prefixlen 64 scopeid 0x2 enc0: flags=0 priority: 0 groups: enc status: active vlan4091: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:22:19:d6:9c:05 priority: 0 vlan: 4091 priority: 0 parent interface: bge1 groups: vlan status: active inet6 fe80::222:19ff:fed6:9c05%vlan4091 prefixlen 64 scopeid 0x5 inet 66.150.7.126 netmask 0xff80 broadcast 66.150.7.127 vlan4092: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:22:19:d6:9c:05 priority: 0 vlan: 4092 priority: 0 parent interface: bge1 groups: vlan status: active inet6 fe80::222:19ff:fed6:9c05%vlan4092 prefixlen 64 scopeid 0x6 inet 72.5.215.254 netmask 0xff00 broadcast 72.5.215.255 vlan4093: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:22:19:d6:9c:05 priority: 0 vlan: 4093 priority: 0 parent interface: bge1 groups: vlan status: active inet6 fe80::222:19ff:fed6:9c05%vlan4093 prefixlen 64 scopeid 0x7 inet 66.150.173.62 netmask 0xffc0 broadcast 66.150.173.63 -Original Message- From: Ted Unangst [mailto:ted.unan...@gmail.com] Sent: Wednesday, December 01, 2010 2:52 PM To: Geoff Sweet Cc: misc@openbsd.org Subject: Re: Using OpenBSD as a router On Wed, Dec 1, 2010 at 5:41 PM, Geoff Sweet geoff.sw...@wemadeusa.com wrote: I have been googling this issue today and I am finding that I don't quite know enough about what I am doing, and that the terms I am searching for are not returning the results I want. I have need of using OpenBSD as a router temporarily. I have four interfaces. bge0 - my primary interface that will be facing my ISP's border router bge1: +vlan1 - Segment for my subnet1 +vlan2 - Segment for my subnet2 +vlan3 - Segment for my subnet3 So I really only want routing functionality so I thought it was safe to do the following: - Set net.inet.ip.fordwarding=1 - Disabled PF This leaves me in a state where I can ping hosts in vlan1 from the network on bge0. But that's about it. I kinda don't know the right questions to ask here. Googling for routing leads to mostly sites dealing with adding static routes in OpenBSD. So from some of the reading on Faq6, I assumed that enabling forwarding would leave me with a system whereby packets entering any of the interfaces would be routed back out the correct interface for the subnet, or off onto the default gateway if no local subnet exists. But that assumption seems to be failing me. The faq also mentioned OpenBGPD and routed, but there doesn't appear to be any man page for routed and because my ISP is statically routing my subnets to me, apparently (according
strange crash with 4.5
We are in the midst of migrating all our firewalls to 4.6. However I have a now-recurring issue on one of my last 4.5 (amd64) firewalls that I'm having a hard time understanding. It's happening right now so if there is something I can do in this state to show what's going on, i'd like to do it. Current this firewall performs duty for inbound customer traffic for some game clients (mmo style) and for firewall enforcement between various vlans on the inside. The first time this happened I thought it was just a fluke. Current state of the system: The system won't let me log in via ssh. I can make a tcp connection via telnet so I know that at least something is listening on the port, but nothing I try will get the system to prompt me for authentication credentials. No love on the terminal either. Because our datacenter uses KVM and the keyboard switches via USB, it won't detect the keyboard being plugged in. However I can get video and it was left logged in with top running, and it appears to be frozen. Just like the previous time the event was preceeded by increased complaints from our customers that game lag was very high. I know this all seems very vague, but I am totally frustrated here. We don't move a lot of traffic, 40mbps at the most. It still continues to firewall traffic without too much issue. Last time this happened, when I rebooted I couldn't find anything in the logs to suggest an error of any type. Could I be running out of resources somewhere? Thanks for your insight, Geoff Sweet
Re: PF rule problems using tables
In case this helps anyone, I discovered the issue with this. Since the
IP I am trying to ban has state entries, PF tries very hard to not
disturb existing connections and thus doesn't kill the connection even
though it is listed in the table that is associate with the block quick
rule in pf.conf.
So after I update the blocked_ip list with the desired IP I run this:
pfctl -k ip_address
before reloading the rules and tables with the -f switch. Kills the
state entries and leaves the user high and dry on the public side of the
firewall.
-Geoff Sweet
-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf
Of Geoff Sweet
Sent: Friday, July 31, 2009 11:34 AM
To: misc@openbsd.org
Subject: PF rule problems using tables
Greetings all,
I have very successfully been using OpenBSD 4.5 to manage both our
corporate firewall as well as the firewall in our production gaming
environment. However recently I have been given the task from the home
office to do some basic regional IP blocking. Great thinks I, I will
create a table and at the same time create an extra table for the IP's
of spammers and users whom we want to keep out of our game.
So in my pf.conf I created two tables:
table blocked_ip persist file /etc/blocked_ip
table asian_ip persist file /etc/blocked_asian_ip
blocked_ip is the table for the occasional user we want to boot, and
blocked_asian_ip is a list of ip nets in select asian countries that we
want to disallow. Right now blocked_asian_ip is empty and blocked_ip
looks like this:
220.249.167.192
208.43.3.90
123.128.151.190
60.217.150.82
98.126.4.99
74.222.14.10
60.217.153.214
222.135.105.242
114.108.128.220
71.137.134.82
174.139.11.22
121.156.65.187
210.118.194.65
Nothing looks wrong so far to me. So then I added a block in quick rule
in my pf.conf to blackhole these tables of ip's. Here is my complete
pf.conf:
# macros
ext_if=vlan2
int_if=vlan5
slbnet_if=vlan3
adminnet_if=vlan4
# service groups
priv_tcp_services={ 8020 }
sql_port={ 1433 }
rdp_services={ 3389 }
icmp_types=echoreq
crm_ports={80 443 8080}
# These are IP's that are allowed full access
trusted_hosts={24.16.115.5 203.238.151.208 203.238.151.216
203.238.151.210 203.238.151.217 67.18.69.66 222.110.172.248
76.121.252.154 71.121.162.98 98.117.116.77}
payment_gateway={66.211.168.126 217.22.128.136 217.22.128.227
207.46.232.182 128.30.52.170 128.30.52.38 128.30.52.51 128.30.52.52
128.30.52.53 128.30.52.54 128.30.52.166 128.30.52.168 216.167.121.109}
# internal private hosts
ad1=10.1.0.10
sql1=10.1.1.1
sql2=10.1.1.2
sql3=10.1.1.3
sql4=10.1.1.4
mirsrv1=10.3.2.1
mirsrv2=10.3.2.2
mirsrv3=10.3.2.3
mirsrv4=10.3.2.4
webbill=10.3.2.20
webbillms=10.1.2.20
billtest=10.3.2.21
crm=10.1.2.21
billadmin=10.3.2.22
web1=10.3.1.1
web2=10.3.1.2
sql5=10.1.1.5
web3=10.3.1.3
monitor1=10.1.0.20
# banned IP addresses
table testgeoff persist
table blocked_ip persist file /etc/blocked_ip
table asian_ip persist file /etc/blocked_asian_ip
# options
set block-policy return
set loginterface $ext_if
set skip on lo
# scrub
scrub in
# nat/rdr
nat on $ext_if from !($ext_if) - ($ext_if:0)
nat on $slbnet_if from $trusted_hosts - ($slbnet_if:0)
nat-anchor ftp-proxy/*
rdr-anchor ftp-proxy/*
rdr pass on $int_if proto tcp to port ftp - 127.0.0.1 port 8021
# Temporary remote connections for RDP from the Korean offices
rdr on $ext_if proto tcp from $trusted_hosts to 66.150.173.5 port 4100
- $sql1 port 3389
rdr on $ext_if proto tcp from $trusted_hosts to 66.150.173.5 port 4101
- $sql2 port 3389
rdr on $ext_if proto tcp from $trusted_hosts to 66.150.173.5 port 4102
- $sql3 port 3389
rdr on $ext_if proto tcp from $trusted_hosts to 66.150.173.5 port 4103
- $sql4 port 3389
rdr on $ext_if proto tcp from $trusted_hosts to 66.150.173.5 port 4104
- $mirsrv1 port 3389
rdr on $ext_if proto tcp from $trusted_hosts to 66.150.173.5 port 4105
- $mirsrv2 port 3389
rdr on $ext_if proto tcp from $trusted_hosts to 66.150.173.5 port 4106
- $mirsrv3 port 3389
rdr on $ext_if proto tcp from $trusted_hosts to 66.150.173.5 port 4107
- $mirsrv4 port 3389
rdr on $ext_if proto tcp from $trusted_hosts to 66.150.173.5 port 4108
- $webbill port 3389
rdr on $ext_if proto tcp from $trusted_hosts to 66.150.173.5 port 4109
- $webbillms port 3389
rdr on $ext_if proto tcp from $trusted_hosts to 66.150.173.5 port 4110
- $billtest port 3389
rdr on $ext_if proto tcp from $trusted_hosts to 66.150.173.5 port 4111
- $crm port 3389
rdr on $ext_if proto tcp from $trusted_hosts to 66.150.173.5 port 4112
- $billadmin port 3389
rdr on $ext_if proto tcp from $trusted_hosts to 66.150.173.5 port 4113
- $web1 port 3389
rdr on $ext_if proto tcp from $trusted_hosts to 66.150.173.5 port 4114
- $web2 port 3389
rdr on $ext_if proto tcp from $trusted_hosts to 66.150.173.5 port 4115
- $sql5 port 3389
rdr on $ext_if proto tcp from $trusted_hosts to 66.150.173.5 port 4116
- $web3
PF rule problems using tables
to 66.150.173.6 port 7100 - $mirsrv4
rdr on $ext_if proto tcp from any to 66.150.173.6 port {7200 7201 7202
7203 7204 7205} - $mirsrv4
rdr on $ext_if proto tcp from $trusted_hosts to 66.150.173.10 port 80 -
$crm port 80
rdr on $ext_if proto tcp from $trusted_hosts to 66.150.173.10 port 443
- $crm port 443
rdr on $ext_if proto tcp from $trusted_hosts to 66.150.173.10 port 8080
- $crm port 8080
# filter rules
block in log
block in log quick from blocked_ip to any
block in log quick from asian_ip to any
block in log quick from testgeoff to any
pass out keep state
anchor ftp-proxy/*
antispoof quick for { lo $int_if }
# Rules to pass in on the external interface for local services
pass in on $ext_if inet proto tcp from any to ($ext_if) port
$priv_tcp_services flags S/SA keep state
#
# Rules to pass in for rdr rules
#
pass in on $ext_if inet proto tcp from $trusted_hosts to $crm port
$crm_ports flags S/SA keep state
pass in on $ext_if inet proto tcp from $trusted_hosts to {$sql1 $sql2
$sql3 $sql4 $mirsrv1 $mirsrv2 $mirsrv3 $mirsrv4 $webbill $webbillms
$billtest $crm $billadmin $web1 $web2 $sql5 $web3} port 3389 keep state
pass in on $ext_if inet proto tcp from $trusted_hosts to {$sql1 $sql2
$sql3 $sql4 $billtest $sql5} port 1433 keep state
pass in on $ext_if inet proto {tcp udp} from any to $mirsrv1 port 7000
flags S/SA keep state
pass in on $ext_if inet proto {tcp udp} from any to $mirsrv4 port {7100
7200 7201 7202 7203 7204 7205} flags S/SA keep state
#
# Rules inbound for the slbnet
#
pass in on $slbnet_if from 10.3.0.0/16 to {$ad1 $monitor1} keep state
pass in on $slbnet_if inet proto tcp from 10.3.0.0/16 to {$sql1 $sql2
$sql3 $sql4 $sql5 $billtest} port $sql_port keep state
pass in on $slbnet_if inet proto {tcp udp} from 10.3.0.0/16 to
$webbillms port {21001 21011} keep state
pass in on $slbnet_if inet proto udp from $mirsrv3 to $sql2 port 10001
keep state
pass in on $slbnet_if inet proto tcp from $billtest to 192.168.16.46
port 1433 keep state
# Allow in certain ICMP traffic
pass in inet proto icmp all icmp-type $icmp_types keep state
# Allow traffic from the internal network to make any connection to the
outside world.
# this rule needs to be deleted in next change request as redundant
pass in on $int_if from 10.1.0.0/16 to 10.3.0.0/16 keep state
pass in quick on $int_if
However when I go to add an additional IP to the table, nothing happens.
I append the address to the blocked_ip file, then I issue pfctl -f
/etc/pf.conf. I can see via tcpdump quite clearly that a given user, in
this case 114.108.128.220, is allowed in through the firewall. And if I
test for the the IP:
sudo pfctl -t blocked_ip -T test 114.108.128.220
1/1 addresses match.
So what gives? Do I need to do something additional to get it to reload
all the table information?
Thanks everyone.
Geoff Sweet
Operations Engineer
WeMade Entertainment USA.
Re: hide NAT with OpenBSD
That's why you set min-ttl to it's highest value. You could also look at 'reassemble tcp'. It modifies ttl setting in the session as well. But it's meant more for normalizing traffic. -Geoff Alexey S. Malyshev wrote: On Sun, 30 Oct 2005 10:00:25 -0500 Jeff Quast [EMAIL PROTECTED] wrote: scrub on $ext_if min-ttl 255 On 10/30/05, Alexey S. Malyshev [EMAIL PROTECTED] wrote: Hi misc@ How to set TTL to certain value on a certain interface in order to hide presence of LAN behind NAT? hmm... but if TTL == 128 and min-ttl == 64, than packets not scrubed by PF... and anti-NAT systems block this ip FreeBSD has `IPSTEALTH', OpenBSD have anything to do this? sorry, my english is very, very bad =(
