Re: Problem with transparent bridge + PF
Hi Kyle, Our configuration is the same (no IP address on each of the bridge interfaces). Do you think you could send me a sanitized version of your pf.conf? We've been playing around with this for over a week now and have not had any luck getting this set-up to work. Thanks, Tim On Mon, 17 May 2010, Kyle Lanclos wrote: Date: Mon, 17 May 2010 14:43:39 -0700 From: Kyle Lanclos To: Tim Miller Subject: Re: Problem with transparent bridge + PF That's the same fundamental network configuration that we have. It almost sounds like you have a problem with asymmetric routing. On our system, the two bridge interfaces do not have any IP configuration of any kind, other than 'up' in the appropriate hostname.em# files. --Kyle -- tmil...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Problem with transparent bridge + PF
Hi Everybody, I'm encountering a problem routing packets from the management interface of my OpenBSD 4.6 system through a transparent bridge on the same machine. Our basic set-up is we have a large-ish LAN behind the OpenBSD box. The OpenBSD box acts as a firewall between the LAN and the outside world. This is accomplished by having a transparent bridge running on the OpenBSD box that connects the rest of the LAN to the router, i.e.: ++ ++++ | LAN |<- em2 ->| Transparent bridge |<- em3->| Router | ++ ++++ Note: em2 and em3 are the two interfaces on the OpenBSD box that make up the transparent bridge. Also, the OpenBSD box has a management interface (em0) which connects to the LAN switch. All of the firewall rules between the LAN and the router appear to be working correctly and traffic is passed as we expect *except* when it originates from the management interface (em0). If we disable PF or we put "skip on em0" in the pf.conf, traffic from the management interface to the outside world passes over the bridge as expected. If however, PF is enabled on em0, it doesn't work. I've reduced the filter set to the smallest possible that reproduces the problem: block log all pass log quick on em0 pass log quick on em2 pass log quick on em3 inet proto udp from any to port 53 pass log quick on em3 inet proto udp from port 53 to any We're using DNS as an example, but we've verified that this happens with all traffic. The strange thing is that if we run a tcpdump on pflog0, we don't see any traffic being blocked. Furthermore, if we run tcpdump on em0, we see the DNS request and reply packets cross the interface. This indicates to us that the DNS reply packet from the DNS server is getting back to the machine, but is not being passed to the application for some reason. We also noticed something else strange: when any host other than the management IP sends a DNS request packet, we see the packet pass in on em2 and out on em3. When the management interface sends a DNS packet out, we see it pass in on em2 but we don't ever see it pass out em3 (it must reach the router somehow, though, because as mentioned we do see the response packet from the server). At this point, I'm really not sure what's going on. Traffic from the management interface should in theory be treated the same as any other traffic crossing the bridge, but that doesn't seem to be the case. If anyone could provide any suggestions of where we're going wrong here, they would be much appreciated. Unfortunately, the way our network is designed requires that our firewall operate on a transparent bridge. Best Wishes, Tim Miller
Bridge architecture question
Hello, I've got a SDSL line with a 8 public IP bloc I would like to build an openBSD 4.5 in a bridge configuration with 3 interface. Here is the architecture : === [ rl1 ] = SERVER1 PUB_IP_1 ==| | | SDSL =[ rl0 ]= OpenBSD = |== LAN | | === [ rl2 ] = SERVER2 PUB_IP_2 == The clients will be acceding to both services offered by SERVER1 and SERVER2 : - SERVER1 is a full H323 video conferencing server and is the gatekeeper - SERVER2 is a web video conferencing server over HTTP/HTTPS My goal is to build the OpenBSD machine as a bridge with multiple public IPs (in order not to mess with H323 and NAT problems) Is this configuration possible ? Will both SERVERS receive their IP and will be able to communicate over the SDSL link ? I also would like to : - Limit global SDSL link at 4 megs - Allow each link to use all of the bandwith up to 4 mega if the other is unused - But try to give an equal bandwidth to each link - Filters some dangerous ports with pf Can somebody give me some help with this case ? Regards Romain -- View this message in context: http://www.nabble.com/Bridge-architecture-question-tp25022682p25022682.html Sent from the openbsd - packet filter mailing list archive at Nabble.com.
combine bridge with PF
Hello, I'm new to OpenBSD and I'm looking for clarification on some issues I have when combining a bridge with PF. My scenario is as follows: I have two interfaces member of a bridge(4). I want to sort out of the bridge some TCP connections, say to port X. These are assumed to arrive always on one interface and be destined to the other. I divert such connections via PF to 127.0.0.1:Y. A proxy-like daemon listening here processes such data and wants to reconnect to the actual destination. It uses the SO_BINDANY option for spoofing the client's address for this purpose. A first problem I get is that the divert-to rule fails to work if none of the interfaces of the bridge are configured with an IP. I see the SYN packet arriving to 127.0.0.1:Y, but I never see the SYN/ACK coming back (both when sniffing the arrival interface, lo0, and pflog0). I don't have an intuition of the motivation for this. A second problem I have is that the ARP table ends up associating all MAC addresses to one same interface of the bridge (the one configured), no matter where they actually came from. If address A is on $int_if, arp -a holds "A at MAC_A on $ext_if", and all connections made to A cause a SYN to be copied to both $ext_if and $int_if. Although connections are still successful, it is disturbing to have the garbage SYN on $ext_if for a number of reasons, like breaking the network transparency of the device, logging noise, annoyance to IDS et al. A third problem I have is with getting back connections with spoofed addresses. When I assign the (spoofed) address A to a socket for connecting to B (on the side of $int_if): - from B, I see the SYN arriving and RST coming back - this is reflected on $int_if on the bridge, and on pflog0 (with "log (all)") - the packet is *not* copied on $ext_if, for a seemingly successful divert out of the bridge - I see the SYN packet logged by the divert-reply rule - the application never gets the answer on the socket - if I change the divert-reply rule making it "on $int_if" only, pflog0 shows the packet is not matched anymore by the rule. Btw, I didn't expect this as bridge(4)'s NOTES section reports that PF will get a packet on both interfaces it is copied to. I use the attached foo.c to reproduce the proxy connecting with SO_BINDANY, and the attached pf.conf file for PF. Any help for further investigation is appreciated, I don't have more ideas. foo.c Description: Binary data pf.conf Description: Binary data
Re: Failover bridge(4) with RSTP
Jason Dixon escribió: I'm attempting to setup a failover bridge(4) configuration with RSTP for rapid failover. At this point I'm still tweaking the bridges and switches. We're using a Foundry LS648 for this test, so we don't have Cisco's "unplinkFast" extension at our disposal. We have two VLANs configured on the switch, each with 802.1w enabled and functioning normally. Plugged into each VLAN is a single client and one interface from each firewall. 10.20.0.2 <-> vlan200 <-> bridge0 <-> vlan300 <-> 10.20.0.3 Regardless of whether I use rstp (default) or stp (+ ifpriority/ifcost) on the bridges, it always takes ~5 minutes to failover. I noticed that with stp enabled on the physical interfaces, the switch would immediately show the correct bridge as the forwarding root. With the default rstp, the switch shows all ports as designated forwarding. I've also tried disabling learning on the internal interfaces and adding static entries for 10.20.0.3, but this has no effect on the recovery time. Any suggestions on getting a rapid failover working? I've got a pair of OpenBSD 4.2 boxes using RSTP perfectly with two DlinK common switches. They've been working fine during last year and the redundancy is completely checked and reliable using RSTP. Maybe the "problem" is the VLAN; I've not worked with VLAN in this scenario and indeed I've suffering some VLAN/pf/bridge related-troubles . The picture is sw01 <---> fw1 <> sw02 sw01 <---> fw2 <> sw02 and config is $ cat /etc/hostname.em0 up [r...@ares] [~] [18:19:21] $ cat /etc/hostname.em1 up [r...@ares] [~] [18:19:23] $ cat /etc/hostname.em2 inet 192.168.1.253 255.255.0.0 NONE [r...@ares] [~] [18:19:25] $ cat /etc/hostname.em3 inet 10.10.10.1 255.255.255.0 NONE [r...@ares] [~] [18:19:27] $ cat /etc/bridgename.bridge0 add em1 add em0 -learn em1 -learn em0 stp em1 stp em0 up [r...@ares] [~] [18:19:37] $ cat /etc/hostname.pfsync0 up syncdev em3 In both Dlink switches I've enabled RSTP support and simple make the lower cost for fw01 path and more cost for fw02. Even I have a simple "last-resort" wire with the higer RSTP cost. -- Thanks, Jordi Espasa Clofent
Failover bridge(4) with RSTP
I'm attempting to setup a failover bridge(4) configuration with RSTP for rapid failover. At this point I'm still tweaking the bridges and switches. We're using a Foundry LS648 for this test, so we don't have Cisco's "unplinkFast" extension at our disposal. We have two VLANs configured on the switch, each with 802.1w enabled and functioning normally. Plugged into each VLAN is a single client and one interface from each firewall. 10.20.0.2 <-> vlan200 <-> bridge0 <-> vlan300 <-> 10.20.0.3 Regardless of whether I use rstp (default) or stp (+ ifpriority/ifcost) on the bridges, it always takes ~5 minutes to failover. I noticed that with stp enabled on the physical interfaces, the switch would immediately show the correct bridge as the forwarding root. With the default rstp, the switch shows all ports as designated forwarding. I've also tried disabling learning on the internal interfaces and adding static entries for 10.20.0.3, but this has no effect on the recovery time. Any suggestions on getting a rapid failover working? Thanks, -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net/
Re: Single VLAN through bridge
Jordi Espasa Clofent writes: > Altought, the problem comes when it try to enable PF. I don't know why > but I've the suspicion that it's an VLAN related issue. I think that you need to filter on vlan interfaces. From what I remember, the vlan-tagged traffic passing through the same interfaces will not be filtered at all if you specify the physical interfaces. Basically, create /etc/hostname.vlan0 and /etc/hostname.vlan1 like this: vlan 1 vlandev em0 up vlan 1 vlandev em1 up Then add vlan0 and vlan1 to the bridge instead of the actual interfaces, and filter on vlan0, vlan1 in your pf.conf, just like you would for regular interfaces. -- Arcady Genkin : CDF Systems Administrator http://www.cdf.toronto.edu/~agenkin/
Single VLAN through bridge
Hi all,
I've a OpenBSD box (4.2) with a bridge; through it passes a single VLAN.
No problem here.
The bridge config is easy:
$ cat /etc/hostname.em1
up
$ cat /etc/hostname.em0
up
$ cat /etc/bridgename.bridge0
add em1
add em0
-learn em1
-learn em0
stp em1
stp em0
up
Altought, the problem comes when it try to enable PF. I don't know why
but I've the suspicion that it's an VLAN related issue.
My /etc/pf.conf is simple:
# 1. Macros
ext_if="em1"
int_if="em0"
bridge="{" $ext_if $int_if "}"
admin_if="em2"
pfsync_if="em3"
my_net="xxx.xxx.xxx.xxx/xx"
# 2. Tables
table persist file "/etc/pf_files/unfiltered.pf"
table persist file "/etc/pf_files/special.pf"
table persist file "/etc/pf_files/restricted.pf"
table persist
table persist
table persist
table persist
# 3. Options
set skip on lo
set skip on em0
set skip on em2
set skip on em3
set fingerprints "/etc/pf.os"
set block-policy drop
set optimization aggressive
set limit states 100
set limit src-nodes 5
set limit frags 15000
set loginterface em1
# 4. Scrub traffic
scrub in all
# 5. QUEUEING
# Not used.
# 6. TRANSLATION
# Not used.
# 7. FILTER RULES
# DEFAULT POLICY
block in on $ext_if
# antispoof
antispoof quick for lo
# allow ping/tracert tools
pass quick on $bridge inet proto icmp from any to any
# permit all outbound traffic
pass out quick
# turning away the brutes
block quick from
block quick from
block quick from
block quick from
block quick from
# unfiltered boxes
pass quick on $bridge inet proto { tcp, udp, icmp } from any to
allow-opts
# allow access special cases
pass quick on $bridge inet proto { tcp, udp } from to any
allow-opts
# www with brute control method
pass quick on $bridge inet proto tcp from any to $my_net port { 80, 443
} keep state \
(max-src-conn 900, max-src-conn-rate 125/1, \
overload flush global) allow-opts
# DNS
pass quick on $bridge inet proto { tcp, udp } from any to $my_net port 53
# smtp with brutes
pass quick on $bridge inet proto tcp from any to $my_net port { 25, 578}
keep state \
(max-src-conn 450, max-src-conn-rate 80/1, \
overload flush global)
# pop3, pop3s, imap4, imap4s
pass quick on $bridge inet proto tcp from any to $my_net port { 110,
143, 993, 995 }
# FTP passive
anchor "ftpsesame/*" in on $bridge proto tcp from any to $my_net
anchor "ftpsesame/*" out on $bridge proto tcp from any to $my_net
# FTP active
anchor "ftpsesame/*" in on $bridge proto tcp from $my_net to any
anchor "ftpsesame/*" out on $bridge proto tcp from $my_net to any
pass in on $bridge inet proto tcp from any to $my_net port 21
# mysql with brutes control
pass quick on $bridge inet proto tcp from any to $my_net port 3306 keep
state \
(max-src-conn 25, max-src-conn-rate 10/5, \
overload flush global)
# PostgreSQL
pass quick on $bridge inet proto tcp from any to $my_net port 5432
# SSH
pass quick on $bridge inet proto tcp from any to $my_net port 22 keep
state \
(max-src-conn 20, max-src-conn-rate 3/12, \
overload flush global)
# ntp server public server es.pool.ntp.org
pass quick on $bridge inet proto udp from any to xxx.xxx.xxx.xxx port 123
$ ifconfig
lo0: flags=8049 mtu 33168
groups: lo
inet 127.0.0.1 netmask 0xff00
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6
em0: flags=8943 mtu 1500
lladdr 00:15:17:4b:0f:4b
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet6 fe80::215:17ff:fe4b:f4b%em0 prefixlen 64 scopeid 0x1
em1: flags=8943 mtu 1500
lladdr 00:15:17:4b:0f:47
media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
status: active
inet6 fe80::215:17ff:fe4b:f47%em1 prefixlen 64 scopeid 0x2
em2: flags=8843 mtu 1500
lladdr 00:30:48:8c:a1:12
groups: egress
media: Ethernet autoselect (1000baseT full-duplex,rxpause)
status: active
inet 192.168.1.253 netmask 0x broadcast 192.168.255.255
inet6 fe80::230:48ff:fe8c:a112%em2 prefixlen 64 scopeid 0x3
em3: flags=8843 mtu 1500
lladdr 00:30:48:8c:a1:13
media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
status: active
inet 10.10.10.1 netmask 0xff00 broadcast 10.10.10.255
inet6 fe80::230:48ff:fe8c:a113%em3 prefixlen 64 scopeid 0x4
enc0: flags=0<> mtu 1536
pfsync0: flags=41 mtu 1460
pfsync: syncdev: em3 syncpeer: 224.0.0.240 maxupd: 128
groups: carp pfsync
pflog0: flags=141 mtu 33168
groups: pflog
bridge0: flags=41 mtu 1500
groups: bridge
--
Thanks,
Jordi Espasa Clofent
Filtering on bridge
Hi all,
I've a pf-based bridged box. The pf.conf file look like:
# 1. Macros
ext_if="em1"
int_if="em0"
bridge="{" $ext_if $int_if "}"
admin_if="em2"
pfsync_if="em3"
my_net="xxx.xxx.xxx.xxx/23"
# 2. Tables
table persist file "/etc/pf_files/unrestricted.pf"
# brutes tables
table persist
table persist
table persist
table persist
# 3. Options
set skip on lo
set skip on em0
set skip on em2
set skip on em3
set fingerprints "/etc/pf.os"
set block-policy drop
set optimization aggressive
set limit states 70
set loginterface em1
# 4. Scrub traffic
scrub in all
# 5. QUEUEING
# Not used.
# 6. TRANSLATION
# Not used.
# 7. FILTER RULES
# DEFAULT POLICY
block in on $ext_if
# antispoof
antispoof quick for lo
# allow ping/tracert tools
pass in inet proto icmp from any to any
# permit all outbound traffic
pass out quick
# turning away the brutes
block quick from
block quick from
block quick from
block quick from
# allow housing without restrictions
pass quick on $bridge inet proto { tcp, udp, icmp } from any to
allow-opts
# www with brute control method
pass quick on $bridge inet proto tcp from any to $my_net port { 80, 443
} keep state \
(max-src-conn 650, max-src-conn-rate 80/1, \
overload flush global)
# DNS
pass quick on $bridge inet proto { tcp, udp } from any to $my_net port 53
# smtp with brutes
pass quick on $bridge inet proto tcp from any to $my_net port { 25, 578}
keep state \
(max-src-conn 250, max-src-conn-rate 50/1, \
overload flush global)
# pop3, pop3s, imap4, imap4s
pass quick on $bridge inet proto tcp from any to $my_net port { 110,
143, 993, 995 }
[ other similar rules ...]
As you can see, I always use 'pass quick on $bridge .', but you can
also note that the bridge is formed by $ext_if (em1, externa NIC) and
$int_if (em0, internal NIC) and I DON'T filter anything in em0 (option
'set skip on em0').
So, I think it will be better using 'pass quick on $ext_if';
¿Am I wright?
--
Thanks,
Jordi Espasa Clofent
bridge with management interface
Hi Folks We have a pf bridge which manages traffic into and out our our residence network. The external interface of this box is on our DMZ which is separated from our main network by another pf bridge. Default route from the resnet firewall is out to the dMZ. This box also has a management interface which is connected to the internal network. If you ssh to the management interface then the box sends the syn+ack out the default route to the dmz where is is blocked by the perimeter router. Is there anyway with a bridge set up that I can tag the incoming ssh traffic so pf will direct the returning traffic to the correct interface. Russell
allowing tftp through a transparent bridge
Hi, We would be extremely grateful if somebody can give us pointers on how to accomplish the following task. We have a transparent bridge between two (routable) networks. We would like to protect a server on one side of the bridge (side A) from a number of hosts on the other side (side B), but would like to make an exception and allow tftp through the bridge from the hosts on side B to the server on side A. So far, we've tried tftp-proxy running on the firewall itself, but without much success. Thanks! Iordan Iordanov CDF System Administrator, University of Toronto
what happens to a bridge if pf is disabled?
HI again folks. Our investigations are progressing and it now looks as if the pf is not the cause of the problems at all ( :-P to the network team ;).The consultant did the right thing and did measurements immediately before and after the firewall and not some distance back into the network (the manager's desktop) as the network folk did (I mean it could not possibly be that their fancy 10G Cisco core was at fault -- could it? snicker..) One test we would like to try is to simply turn off pf for a short period (a minute or two while we make some measurements and see if the video picture improves. Our FW is running in bridge mode so the logical thing to do is simply disable pf (pfctl -d iirc) but I want to be quite sure that this will leave the bridge open. I know logically it should and I have stated that to the change control Gods (on bended knees ;) so it better be true! One other question. Is it possible that the bridge/pf (or something else) is reordering UDP packets? If some packets were delayed then from the video apps view they may as well be dropped if they arrive outside the buffering window. Cheers, Russell (who has finally found a consultant that he approves of ;)
Bridge NAT ALTQ
Hi, all.
I have machine that works like bridge for external routing ip addresses and
NAT for range of rfc1918 addresses.
# uname -a
FreeBSD bignat.isp.ru 6.2-STABLE FreeBSD 6.2-STABLE #0: Fri Sep 28 11:52:21
UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BIG_NAT amd64
# ifconfig lo1
lo1: flags=8049 mtu 16384
inet 80.0.68.12 netmask 0xfffc
inet 80.0.68.13 netmask 0xfffc
inet 80.0.68.14 netmask 0xfffc
inet 80.0.68.15 netmask 0xfffc
inet 80.0.70.130 netmask 0x
# ifconfig bridge0
bridge0: flags=8843 mtu 1500
ether 4e:33:45:7b:a9:74
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto stp maxaddr 100 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: msk0 flags=143
member: em0 flags=143
# ifconfig em0
em0: flags=8943 mtu 1500
options=48
ether 00:0e:0c:a4:3a:cd
media: Ethernet autoselect (1000baseTX )
status: active
# ifconfig msk0
msk0: flags=8943 mtu 1500
options=18
inet 80.0.68.20 netmask 0xfff8 broadcast 80.0.68.23
ether 00:0e:0c:a4:3a:cc
media: Ethernet autoselect (1000baseTX )
status: active
# netstat -rn
Routing tables
Internet:
DestinationGatewayFlagsRefs Use Netif Expire
default80.0.68.17 UGS 0 576233 msk0
10 lo0URS 0 10lo0
80.0.68.12 80.0.68.12 UH 00lo1
80.0.68.13 80.0.68.13 UH 00lo1
80.0.68.14 80.0.68.14 UH 00lo1
80.0.68.15 80.0.68.15 UH 00lo1
80.0.68.16/29link#1 UC 00 msk0
80.0.68.17 00:11:bb:a6:15:80 UHLW20 msk0 1199
80.0.68.18 00:11:93:0c:44:1b UHLW50 msk0467
80.0.68.20 00:0e:0c:a4:3a:cc UHLW1 164lo0
80.0.70.130 80.0.70.130 UH 00lo1
127.0.0.1 127.0.0.1 UH 0 786lo0
127.0.0.2 127.0.0.2 UH 05lo0
127.0.0.3 127.0.0.3 UH 00lo0
127.0.0.4 127.0.0.4 UH 00lo0
172.16/12 lo0URS 00lo0
192.168.0/16 lo0URS 02lo0
192.168.128/19 80.0.68.18 UGS 0 16282333 msk0
192.168.160/19 80.0.68.18 UGS 0 159008 msk0
int_if="em0"
ext_if="msk0"
bridge_if="bridge0"
# NAT
nat-anchor "ftp-proxy/*"
nat on $ext_if inet fromto !(self) -> 80.0.68.12/30 bitmask
nat on $ext_if inet from to !(self) -> 80.0.70.130
#...
#
# bridge
#
pass in on $int_if inet from {} to any
pass out on $int_if inet from anyto {}
queue(q_ext q_eacks)
pass out on $int_if inet fromto {}
queue(q_int q_iacks)
pass out on $int_if inet from to {}
tos 0x20 queue(q_peers)
pass on $ext_if inet all
#
# pfctl -vv -sr
..
@8 pass in on em0 inet from to any
[ Evaluations: 31962419 Packets: 9822781 Bytes: 3723656443 States:
0 ]
@9 pass in on em0 inet from to any
[ Evaluations: 22606139 Packets: 12632981 Bytes: 4251228990 States:
0 ]
@10 pass in on em0 inet from to any
[ Evaluations: 22606139 Packets: 114847Bytes: 27950859States:
0 ]
@11 pass out on em0 inet from any to queue(q_ext, q_eacks)
[ Evaluations: 55912371 Packets: 6342607 Bytes: 1937428659 States:
0 ]
@12 pass out on em0 inet from any to queue(q_ext, q_eacks)
[ Evaluations: 8999665 Packets: 0 Bytes: 0 States:
0 ]
@13 pass out on em0 inet from any to queue(q_ext, q_eacks)
[ Evaluations: 8999665 Packets: 0 Bytes: 0 States:
0 ]
@14 pass out on em0 inet from to queue(q_int, q_iacks)
[ Evaluations: 8999665 Packets: 722131Bytes: 129079550 States:
0 ]
@15 pass out on em0 inet from to queue(q_int, q_iacks)
[ Evaluations: 722131Packets: 0 Bytes: 0 States:
0 ]
@16 pass out on em0 inet from to queue(q_int, q_iacks)
[ Evaluations: 722131Packets: 0 Bytes: 0 States:
0 ]
@17 pass out on em0 inet from to tos 0x20 queue q_peers
[ Evaluations: 8999665 Packets: 1934927 Bytes: 1063519866 States:
0 ]
@18 pass out on em0 inet from to tos 0x20 queue q_peers
[ Evaluations: 3185036 Packets: 0 Bytes: 0 States:
0 ]
@19 pass out on em0 inet from to tos 0x20 queue
q_peers
[ Evaluations: 3185036 Packets: 0 Bytes: 0 Sta
Re: nat and ftp-proxy on ethernet bridge
On Friday 13 July 2007 21:36:13 you wrote: > On 07/09/2007 07:45:58 AM, Igor Popov wrote: > > Bridge works, NAT works, but problems with ftp - control connection is > > > > established, but data connection is dropped. Of course, without > > ftp-proxy > > passive ftp works, but some clients need working active ftp too. > > I don't know FreeBSD but you might try assigning an IP address to > an interface, _and_ bridging. Then you could run ftp-proxy. > Yes it possible: if_bridge ported from NetBSD and pf from OpenBSD. Now ftp-proxy works and CPU load is lower and memory consumption too. Thanks for help. -- Nothing so needs reforming as other people's habits. -- Mark Twain, "Pudd'nhead Wilson's Calendar"
Re: nat and ftp-proxy on ethernet bridge
On 07/09/2007 07:45:58 AM, Igor Popov wrote: Bridge works, NAT works, but problems with ftp - control connection is established, but data connection is dropped. Of course, without ftp-proxy passive ftp works, but some clients need working active ftp too. I don't know FreeBSD but you might try assigning an IP address to an interface, _and_ bridging. Then you could run ftp-proxy. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
nat and ftp-proxy on ethernet bridge
Hi, all.
System is FreeBSD 6.2, it has two em[01] interfaces, there is a bridge between
them and on bridge0 there is NAT for internal adrresses (192.168.0.0/20), all
other packets are switched through bridge:
[PPPoE clients 192.168.0.0/20 and real ip]<--xDSL-->[PPPoE AC
80.0.0.1/29]<-->[em0 FreeBSD bridge&NAT 80.0.0.2/29 em1]<-->80.0.0.4/29[BGP
Router]
Why bridge? Both PPPoE concentrator and BGP router are Cisco routers, there is
dynamic routing (EIGRP) between them, so it must be directly connected.
# ifconfig em0 up
# ifconfig em1 up
# ifconfig bridge0 addm em0 addm em1 up
# ifconfig bridge0 inet 80.0.0.2/29
# route add default 80.0.0.4
# cat /etc/pf.conf
int_if="em0"
ext_if="em1"
bridge_if="bridge0"
tableconst { 192.168.0.0/20 }
table const { 80.250.68.2 80.250.68.3 }
set timeout { src.track 300 }
set skip on lo0
# Normalization
scrub in on $bridge_if from
# NAT
nat-anchor "ftp-proxy/*"
rdr-anchor "ftp-proxy/*"
nat pass on $bridge_if inet tagged ADSL_MAIN_INET -> round-robin
sticky-address
rdr on $int_if inet proto tcp from to any port 21 -> 127.0.0.1 port
8021
no rdr on lo0 from any to any
# Rulezzz
#
# eigrp (cisco dynamic routing)
pass quick proto eigrp
# bridge
pass inet all
# nat marker
pass in on $int_if inet from to !($bridge_if) flags S/SA keep
state tag ADSL_MAIN_INET
# ftp
pass in log on $bridge_if route-to (lo0 127.0.0.1) proto tcp from
to 127.0.0.1 port 8021
anchor "ftp-proxy/*"
Bridge works, NAT works, but problems with ftp - control connection is
established, but data connection is dropped. Of course, without ftp-proxy
passive ftp works, but some clients need working active ftp too.
And, what to do?
--
Don't plan any hasty moves. You'll be evicted soon anyway.
nat on bridge
hi.
I have a question about NAT on bridge.
Network diagram:
[PPPoE clients 192.168.0.0/16 and real ip] <-->[PPPoE concetrator
80.0.0.1/29]<>[em0 FreeBSD bridge and NAT 80.0.0.2/29
em1]<->80.0.0.3/29[BGP Router]
Why bridge? Both PPPoE concentrator and BGP router are Cisco routers, there is
dynamic routing (EIGRP) between them, so it must be directly connected.
OpenBSD should NAT internal ip and bridge all another, is it possible?
ifconfig em0 up
ifconfig em1 up
ifconfig bridge0 addm em0 addm em1 up
ifconfig bridge0 inet 80.0.0.2/29
route add default 80.0.0.3
pf rules:
table const {192.168.0.0/16}
nat on bridge0 tagged TO_NAT tag NATED -> (bridge0)
pass in on em1 all keep state
pass in on em0 inet tag TO_INET keep state
pass in on em0 inet from to any tag TO_NAT keep state
pass out on em1 tagged NATED
pass out on em1 tagged TO_INET
--
You climb to reach the summit, but once
there, discover that all roads lead down.
-- Stanislaw Lem, "The Cyberiad"
Re: Again... transparent bridge + spamd
On Mon, Jan 15, 2007 at 02:53:03PM -0600, Neil Brockman wrote: > You don't mention if the mail server is an OpenBSD machine. Is it? If > so, then you don't really have to place spamd on the bridge. spamd > places a minimal load on its host. Alas, it's a Linux box and it's outdated. It's not normally within my purvue. It's for a sister company (ISP) and the current admin was hitting a wall trying to fight spam. Now, the company mail server that I maintain is obsd w/ spamd, and it runs fine... > If you are not running an OpenBSD mail server, you can redirect through > an OpenBSD box so that the OpenBSD box acts as a firewall of sorts for > the mail server. Since bridges don't have IP addresses of their own you > won't have much luck using spamd on a bridge. This is because the > bridge itself does not accept connections. I did get the setup working on a bridge with an IP address on the external interface, per the undeadly article. Slick as can be, since I can leave the existing mail server in place with all it's intricate config stuff. It's working great, and the stress on the mail server is way down. Pure goodness. The article I mention is at http://undeadly.org/cgi?action=article&sid=20061108134508 -- Darrin Chandler| Phoenix BSD Users Group [EMAIL PROTECTED] | http://bsd.phoenix.az.us/ http://www.stilyagin.com/ |
Re: Again... transparent bridge + spamd
Okay, nevermind! After MORE looking I finally found the article on undeadly with simplest complete configs and it works like a charm. Phew! Thanks for your patience. -- Darrin Chandler| Phoenix BSD Users Group [EMAIL PROTECTED] | http://bsd.phoenix.az.us/ http://www.stilyagin.com/ |
Again... transparent bridge + spamd
I've got something of a crisis helping an admin with a huge spam problem. So I'm trying to put together a transparent bridge with spamd in front of a mail server. I've been reading archive posts here, on misc@openbsd.org and anywhere else I can find, but I'm not getting anywhere. Seems that no matter what I do, traffic goes over the bridge and will not rdr to 127.0.0.1. I tried doing the route-to, etc. Does anyone have this working, and willing to share the secret? Or I will gladly post my configs if someone will help! -- Darrin Chandler| Phoenix BSD Users Group [EMAIL PROTECTED] | http://bsd.phoenix.az.us/ http://www.stilyagin.com/ |
Help with transparent bridge + NAT'd PCs
Hi. I'm having a confusing time with a network setup... this is using pf on OpenBSD 3.8, generic 386 kernel VOIP Phones (public 20.0.0.x/24) mixed with Office PCs (private 192.168.1.x/24) ||| \V/ HW switch | $int_if OpenBSD router (192.168.1. 1) | +--- $ext_if for "PCs ISP" (configured via dhclient) +--- $voip_if for "Phone ISP" (either no addy or 20.0.0. 225, route to 20.0.0. 1) (most public numbers herein changed) There's an internal network with voice-over-IP phones and PCs. The phones have publicly routable addresses, and for them, the OpenBSD router should act like an addressless bridge. The router also all assigns PCs private addresses via DHCP, and gives them access to the big bad internet via pf's NAT. Here's my pf.conf (for the moment:) # Symbolic names for our NICs # public_if is the public interface the computers use. It has an IP address. # bridge_if is a bridge that passes traffic, expected to have no IP address. # If these change also edit /etc/hostname.* and /etc/bridgename.* int_if="fxp0" bridge_if="ep1" public_if="sk0" # pc_net is for our computers, voip_net is for our phones pc_net="192.168.1.0/24" table persist file "/etc/voip_net" # nat: packets going out through $public_if with source address $pc_net will # get translated as coming from the dynamic address of $public_if, creating # state for such packets- so reply packets will be redirected to the # internal address. nat on $public_if from $pc_net to any -> ($public_if) # Use internal FTP proxy rdr pass on $int_if proto tcp from $pc_net to port ftp -> 127.0.0.1 port 8021 # pass all traffic pass quick on lo pass all === other files of note: hostname.ep1: inet 20.0.0.225 255.255.255.0 216.27.176.255 description "VOIP uplink" hostname.fxp0: inet 192.168.1.1 255.255.255.0 192.168.1.255 description "Private subnet interface hostname.sk0: # uplink for office pc traffic dhcp bridgename.bridge0: add fxp0 add ep1 up === Here's what happens: All the PCs can talk to the outside world AOK- until someone picks up a phone. The phones work AOK all the time, but once people start using them, the PCs stop working intermittantly. I set up machines to ping the outside world endlessly, and see them get replies and then not, and then get them again, for no apparent reason. Here's what tcpdump shows me on the internal office interface: # tcpdump -i fxp0 icmp and net 192.168.1.0/24 tcpdump: listening on fxp0, link-type EN10MB 13:36:05.857670 192.168.1.99 > knowngoodhost.com: icmp: echo request 13:36:06.509968 192.168.1.24 > knowngoodhost.com: icmp: echo request 13:36:06.858996 192.168.1.99 > knowngoodhost.com: icmp: echo request 13:36:06.864202 192.168.1.22 > knowngoodhost.com: icmp: echo request requests coming in from my three test office PCs, no replies. What's the traffic on bridge0? # tcpdump -ni bridge0 icmp and net 192.168.1.0/24 tcpdump: WARNING: bridge0: no IPv4 address assigned tcpdump: listening on bridge0, link-type EN10MB 13:39:40.632294 192.168.1.99 > knowngoodhost.com: icmp: echo request 13:39:41.008804 192.168.1.24 > knowngoodhost.com: icmp: echo request 13:39:41.362058 192.168.1.22 > knowngoodhost.com: icmp: echo request Hmm, that traffic used to be nat'ed out of sk0, now it's showing up on the bridge. Retry to be sure... I run /etc/netstart to go back to a more "pristine" state- ok I see all three test PC's are getting responses from their pings. tcpdump shows bridge0 has no traffic from $pc_net. That's what I like. Now I'll pick up a VOIP phone- I make some phone calls, good, all three machines keep pinging, good. I interrupt one ping, wait for the state to expire (check with pfctl -s state), try pinging again- request times out. tcpdump shows my 192.168.1.x traffic on bridge0 again. My understanding was that the kernal would grab the 192.168.1.x traffic coming into $int_if (aka fxp0)- addressed as 192.168.1.1- before the bridge got it. That seems to be the case before the bridge is in use, but once the bridge sees traffic, it grabs the 192.168.1.x packets as well. How can I prevent that? thanks for your time -y
Re: Pftpx & Bridge?
On Mon, Jan 02, 2006 at 03:06:33PM +0100, Henrik Bro wrote: > Hi :) > > I am a little confused about Pftpx / Ftpsesame, and I hope someone can help? Both are written by the same author, Camiel. > > Is Pftpx replacing Ftpsesame ? I do not think so, although pftpx is now in the base distribution, replacing the old ftp-proxy. > And if so, does Pftpx support PF in bridge-mode? you can run pftpx in bridge mode, I suppose, but you will need an IP on the bridge Ftpsesame is better suited to ip'less bridges. > Best regards & happy new year to you all, > > Henrik Bro > >
Pftpx & Bridge?
Hi :) I am a little confused about Pftpx / Ftpsesame, and I hope someone can help? Is Pftpx replacing Ftpsesame ? And if so, does Pftpx support PF in bridge-mode? Best regards & happy new year to you all, Henrik Bro
fxp bridge + scrub = panic (kernel/4604)
Entered as bug kernel/4604. A colleague suggested I post here, as well. Anyway, details are in the bug, but the gist is that bridging Intel cards and using scrub rules in pf results in a kernel panic. It's very easy to reproduce. I'm currently using a VIA single board computer (Commell's LE-564), but I have reproduced this (since 3.6) on an HP Kayak PC, and a Dell Precision. Ruleset that causes panic (commenting 2 scrub rules eliminates panic - I don't know if scrub, in general, causes the panic, or if it's one of the scrub options that I am passing): Interface aliases # Interface aliases for ease of administration. ext_if = "fxp0" # Untrusted (to LAN) int_if = "fxp1" # Trusted (to switch) Traffic Normalization # Prevent fragmentation attacks scrub in on $ext_if all fragment reassemble no-df scrub out on $ext_if all fragment reassemble random-id no-df ### Pass traffic on the loopback interface in either direction pass quick on lo0 all Internal Bridge interface rules # Filter on external interface - in bridge mode, # we only filter on one interface. pass in quick on $int_if all pass out quick on $int_if all ### Don't filter anything and see if we still panic pass in quick on $ext_if all pass out quick on $ext_if all Crash: panic: pool_get(mclpl): free list modified: magic=c6830e9e; page 0xd38cc000; it em addr 0xd38cc800 Stopped at Debugger+0x4: leave RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! ddb> trace Debugger(0,0,0,d38cc800,d05d2760) at Debugger+0x4 panic(d04f6bc0,d04f8b89,c6830e9e,d38cc000,d38cc800) at panic+0x63 pool_get(d05d2760,0,da369b00,1,d06f1dfc) at pool_get+0x315 fxp_start(d0958040,d06f1dfc,e,d09e3c00) at fxp_start+0x2ac bridge_ifenqueue(d09ec000,d0958040,da370300,d0958040,da370300) at bridge_ifenqu eue+0xa2 bridgeintr_frame(d09ec000,da370300,0,d06f) at bridgeintr_frame+0x270 bridgeintr(58,10,10,10,d06f) at bridgeintr+0x6a Bad frame pointer: 0xd06f1e44
Re: HOWTO on spamd+transparent bridge under OpenBSD
You've got a couple of weird things and errors on your page: - You say OpenBSD doesn't support multiple consoles: ctrl+alt+f2 - Using the 3.7 ports tree on 3.6 is not recommended. - tarring and untarring fake-i386 to install a port is just weird. make install should already do that - Why not install screen from a package like jove? - sh /etc/netstart bridge0 will fire up your new bridge without rebooting. That's all I can think of at the moment. _ME On 10/14/05, Graham Toal <[EMAIL PROTECTED]> wrote: > For anyone who is interested, I've written up a document on > how to install OpenBSD, configure it as a transparent bridge, > then install spamd on it. It was written primarily for our > campus computer center who want to know how to do it if something > happens to me (like I get a better job elsewhere for example ;-) ) > but I think I've written it generally enough that it will be > of use to anyone. > > The page is here: > http://wiki.utpa.edu/InfoSec/GreyListingInstall?action=print > > regards > > > Graham > > -- http://erdelynet.com/ Support OpenBSD! http://www.openbsd.org/orders.html
Re: HOWTO on spamd+transparent bridge under OpenBSD
> You've got a couple of weird things and errors on your page: > - You say OpenBSD doesn't support multiple consoles: ctrl+alt+f2 Yup! Thanks. Linux uses ALT-Fkey which I tried. Didn't try adding CTRL. :-/ Assumed it didn't have it, and too busy getting everything else working to go look for it. I've now documented it. > - Using the 3.7 ports tree on 3.6 is not recommended. The only install disk I have is 3.6. I assume that by doing an install over the net, I get the 3.7 system - but some trace of 3.6 seems to have remained because some funny things happened later... > - tarring and untarring fake-i386 to install a port is just weird. > make install should already do that It didn't, it gave an error and did a fake install. It appears to be related to the 3.6/2.7 problem. Other packages installed cleanly. > - Why not install screen from a package like jove? I'd rather forget about packages and use ports for everything, but I thought it was worth mentioning for newbies like myself who spent hours looking for apt-get and yum and emerge etc etc - i.e coming from a linux environment... > - sh /etc/netstart bridge0 will fire up your new bridge without rebooting. Thanks, didn't know that. Actually I just found out that "ifconfig bridge0 create" was the crucial missing step I didn't know. > That's all I can think of at the moment. Apreciate it, thanks. G PS I'm marking all these comments up in he wiki as I reply. Two more emails pending from folks who sent similar corrections...
HOWTO on spamd+transparent bridge under OpenBSD
For anyone who is interested, I've written up a document on how to install OpenBSD, configure it as a transparent bridge, then install spamd on it. It was written primarily for our campus computer center who want to know how to do it if something happens to me (like I get a better job elsewhere for example ;-) ) but I think I've written it generally enough that it will be of use to anyone. The page is here: http://wiki.utpa.edu/InfoSec/GreyListingInstall?action=print regards Graham
Re: Keep state + bridge weirdness
> Traffic flow: > > x.x.12.x -> bridge -> router -> bridge -> x.x.13.x This is exactly what I meant saying the traffic goes twice through the bridge. And this is is also where I experienced my problem too. I also have several subnets that must bounce through the bridge to the router and come back. > > When state was kept on this flow, it would exhibit the weird 96k > stoppage mentioned earlier, regardless of protocol (http, ssh, ftp, > etc) We are probably having the same problem with our user stuck transferring file with http to the Dokeos e-learning CMS. One admin indicated to me that antivirus update with ftp failes once in a while. I do not know if you notice also that using modulate state or synproxy state would prohibit completely ssh as opposed to keep state ? Things are wrong somewhere (in our understanding or as a bug), using bridge in pf with a bouncing traffic back and forth through the bridge to an external router. Two solutions, which are rather workaround might exists mentionned here: - using tag only rules to avoid mentionning interfaces in rules. - using bandwith control like you described. I'all try out and let you know. I feel a little uncomfortable to find the cause of many strange things happening like traffic half blocked and unresponding hosts and not the least: completely hung firewall once in a while. Regards François -- Francois TAMONE - Centre Informatique Ecole d'Ingenieurs de Geneve tel:+41-(22)-338 05 39 Rue de la Prairie 4 fax:+41-(22)-338 05 33 CH-1202 Geneva SWITZERLAND, e-mail:[EMAIL PROTECTED], U=tamone,H=eig,D=unige,C=ch
Re: Keep state + bridge weirdness
On Thu, Jun 09, 2005 at 05:34:40PM +0200, TAMONE Francois - System Engineer wrote: > > And what about performace then ? > Would not this scheme impact double on the kernel in several parts of it ? the bridge was put up with various hosts from his RFC1918 /24 hanging off different bridge interfaces. the router running the bridge exhibited the same network throughput between external hosts while running the bridge with tag-on-in and a pf ruleset ~10-15 lines using only tags (no interfaces) as it did by changing the same two test hosts to individual /30s each connected to one of the bridge interfaces, ( eg, one /30 between hostA and bridge ifaceA, other between B and B ), downing the bridge and turning off pf. ( the purpose of the bridge in his example is to be a firewall between his wired and wireless lans, while allowing him to continue to use the same /24 for any host, as he is accustomed to ). jared - [ openbsd 3.7 GENERIC ( may 29 ) // i386 ]
Re: Keep state + bridge weirdness
> a friend of mine setup a bridge recently, and we had > increased success by tagging in on each component iface > with a unique tag, and then keeping pf.conf only > concerned with tags and not concerned with 'on tel:+41-(22)-338 05 39 Rue de la Prairie 4 fax:+41-(22)-338 05 33 CH-1202 Geneva SWITZERLAND, e-mail:[EMAIL PROTECTED], U=tamone,H=eig,D=unige,C=ch
Re: Keep state + bridge weirdness
Well, I have more information for you regarding topology, and what
appears to fix it.
router->bridge->network (4 consecutive class C's)
The router doesn't do a 255.255.252.0 netmask, but rather aliases out
x.x.12.1, x.x.13.1, etc. The reason for this is that some client
routers are so crappy that they cannot handle a non-255.255.255.0
netmask and this fixed the problem (ugh). So a machine on x.x.12.x was
having trouble reaching a machine on x.x.13.x.
Traffic flow:
x.x.12.x -> bridge -> router -> bridge -> x.x.13.x
When state was kept on this flow, it would exhibit the weird 96k
stoppage mentioned earlier, regardless of protocol (http, ssh, ftp,
etc)
Now, I implemented queueing and assigned localnet to localnet traffic
into an 8.5M queue without keeping state and shoved everything else
into default 1.5M queue and kept state. This solved the problem
handily, so the problem is apparently keeping state on a network with
that exact setup when traffic bounces off an external router.
Relevant bits of pf.conf below:
.
# This contains localnet traffic that does not go out a T (shouldn't be
limited to 1.5 or state tracked)
table persist { x.x.12.0/24 x.x.13.0/24 x.x.14.0/24
x.x.15.0/24 }
.
# External interface
altq on $ext_if cbq bandwidth 10Mb queue { ext int }
queue ext on $ext_if bandwidth 1.5Mb { hogs customer }
queue hogs on $ext_if bandwidth 100Kb
queue customer on $ext_if bandwidth 1.4Mb cbq(borrow default)
queue int on $ext_if bandwidth 8.5Mb cbq(borrow)
# Internal interface
altq on $int_if cbq bandwidth 10Mb queue { ext int }
queue ext on $int_if bandwidth 1.5Mb { hogs customer }
queue hogs on $int_if bandwidth 100Kb
queue customer on $int_if bandwidth 1.4Mb cbq(borrow default)
queue int on $int_if bandwidth 8.5Mb cbq(borrow)
# Pass quick all of our local traffic in the int queue
pass quick on { $ext_if $int_if } from to queue
int
# Modulate state on all connections
pass on $ext_if modulate state
If state is kept on the localnet line, then it breaks. (luckily, I
don't really care much about state there anyway, and it's probably
because I'm trying to do something silly anyway, that happens often)
On a somewhat related note, the localnet rule applies if I specify each
class C but the rule ceases to match if I use a CIDR x.x.12.0/22.
Kelley Reynolds
President
Inside Systems, Inc.
Re: Keep state + bridge weirdness
> >>On Jun 6, 2005, at 9:27 AM, Jason Dixon wrote: ..> >>> Try the following rule: > >>> > >>>pass on rl0 keep state i've a limited experience with a bridge so far, but what about, say: --bridgename.bridge0-- add rl0 add rl1 rule pass in on rl0 tag rl0 rule pass in on rl1 tag rl1 up -- --pf.conf-- pass out tagged rl0 keep state --- which would essentially create a state entry based on the packet leaving rl1. a friend of mine setup a bridge recently, and we had increased success by tagging in on each component iface with a unique tag, and then keeping pf.conf only concerned with tags and not concerned with 'on
Re: Keep state + bridge weirdness
On Jun 6, 2005, at 3:00 PM, Kelley Reynolds wrote: On Jun 6, 2005, at 9:27 AM, Jason Dixon wrote: Sorry, missed your comment before about only having that one rule. Well, I'm sure that the rule you've posted will cause you headaches since it's filtering on all interfaces. Try the following rule: pass on rl0 keep state This should create the necessary states, both inbound and outbound, for all traffic. The rule you've attempted not only filters and keeps state on *all* interfaces, but it neglects inbound traffic Man, how I wish that would've worked. Same problem.. FTP dies at 96K. That number has to be significant for something, it's the same every time. You mention that this happens whether the FTP server is on the other side of the bridge or not. Please describe the tests you've performed and where each host resides with regards to the topology. Also, have you tested this with other protocols like scp? -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
Re: Keep state + bridge weirdness
On Jun 6, 2005, at 4:25 PM, Jason Dixon wrote: On Jun 6, 2005, at 3:00 PM, Kelley Reynolds wrote: On Jun 6, 2005, at 9:27 AM, Jason Dixon wrote: Sorry, missed your comment before about only having that one rule. Well, I'm sure that the rule you've posted will cause you headaches since it's filtering on all interfaces. Try the following rule: pass on rl0 keep state This should create the necessary states, both inbound and outbound, for all traffic. The rule you've attempted not only filters and keeps state on *all* interfaces, but it neglects inbound traffic Man, how I wish that would've worked. Same problem.. FTP dies at 96K. That number has to be significant for something, it's the same every time. You mention that this happens whether the FTP server is on the other side of the bridge or not. Please describe the tests you've performed and where each host resides with regards to the topology. Also, have you tested this with other protocols like scp? The client is on the 'inside' of the bridge (rl1) and the FTP server can be on either side, doesn't seem to matter. Other protocols seem to experience vastly degraded performance (no hard numbers though, I will get them as soon as I can) Kelley Reynolds President Inside Systems, Inc.
Re: Keep state + bridge weirdness
On Jun 6, 2005, at 9:27 AM, Jason Dixon wrote: On Jun 6, 2005, at 8:18 AM, Kelley Reynolds wrote: On Jun 6, 2005, at 6:21 AM, Jason Dixon wrote: On Jun 3, 2005, at 6:19 PM, Kelley Reynolds wrote: Having an odd problem... a bridge configured such that one of the interfaces has an IP works fantastically, until pf is enabled with the following rule (and only the following rule) pass out keep state then repeatably, things start to break. Now, when FTPing from one machine to another (whether they are both on the inside of the bridge or not), the transfer will stop after 96k. Every time. If I take off the keep state rule, the transfer will work just fine. Now, on the bottom of 'man bridge', it says that a bridge should only keep state on one interface, so I tried lots of variations of the keep state rule to limit it to one interface, incoming, outgoing, didn't matter. This is on OpenBSD 3.7 with two rl NICs, but this problem also occurred on 3.6. Any ideas? That single rule is the pf.conf, but I'll do it again. Contents of pf.conf (in their entirety, including a commented rule I tried without success): pass out keep state # pass out on rl0 keep state Sorry, missed your comment before about only having that one rule. Well, I'm sure that the rule you've posted will cause you headaches since it's filtering on all interfaces. Try the following rule: pass on rl0 keep state This should create the necessary states, both inbound and outbound, for all traffic. The rule you've attempted not only filters and keeps state on *all* interfaces, but it neglects inbound traffic Man, how I wish that would've worked. Same problem.. FTP dies at 96K. That number has to be significant for something, it's the same every time.
Re: Keep state + bridge weirdness
On Jun 6, 2005, at 8:18 AM, Kelley Reynolds wrote: On Jun 6, 2005, at 6:21 AM, Jason Dixon wrote: On Jun 3, 2005, at 6:19 PM, Kelley Reynolds wrote: Having an odd problem... a bridge configured such that one of the interfaces has an IP works fantastically, until pf is enabled with the following rule (and only the following rule) pass out keep state then repeatably, things start to break. Now, when FTPing from one machine to another (whether they are both on the inside of the bridge or not), the transfer will stop after 96k. Every time. If I take off the keep state rule, the transfer will work just fine. Now, on the bottom of 'man bridge', it says that a bridge should only keep state on one interface, so I tried lots of variations of the keep state rule to limit it to one interface, incoming, outgoing, didn't matter. This is on OpenBSD 3.7 with two rl NICs, but this problem also occurred on 3.6. Any ideas? That single rule is the pf.conf, but I'll do it again. Contents of pf.conf (in their entirety, including a commented rule I tried without success): pass out keep state # pass out on rl0 keep state Sorry, missed your comment before about only having that one rule. Well, I'm sure that the rule you've posted will cause you headaches since it's filtering on all interfaces. Try the following rule: pass on rl0 keep state This should create the necessary states, both inbound and outbound, for all traffic. The rule you've attempted not only filters and keeps state on *all* interfaces, but it neglects inbound traffic. -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
Re: Keep state + bridge weirdness
On Jun 6, 2005, at 6:21 AM, Jason Dixon wrote: On Jun 3, 2005, at 6:19 PM, Kelley Reynolds wrote: Having an odd problem... a bridge configured such that one of the interfaces has an IP works fantastically, until pf is enabled with the following rule (and only the following rule) pass out keep state then repeatably, things start to break. Now, when FTPing from one machine to another (whether they are both on the inside of the bridge or not), the transfer will stop after 96k. Every time. If I take off the keep state rule, the transfer will work just fine. Now, on the bottom of 'man bridge', it says that a bridge should only keep state on one interface, so I tried lots of variations of the keep state rule to limit it to one interface, incoming, outgoing, didn't matter. This is on OpenBSD 3.7 with two rl NICs, but this problem also occurred on 3.6. Any ideas? That single rule is the pf.conf, but I'll do it again. Contents of pf.conf (in their entirety, including a commented rule I tried without success): pass out keep state # pass out on rl0 keep state Contents of `ifconfig -a`: # ifconfig -a lo0: flags=8049 mtu 33224 inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 rl0: flags=8943 mtu 1500 address: 00:50:fc:54:eb:2f media: Ethernet autoselect (100baseTX full-duplex) status: active inet 216.207.12.2 netmask 0xff00 broadcast 216.207.12.255 inet6 fe80::250:fcff:fe54:eb2f%rl0 prefixlen 64 scopeid 0x1 rl1: flags=8943 mtu 1500 address: 00:0e:2e:2a:a1:90 media: Ethernet autoselect (100baseTX full-duplex) status: active inet6 fe80::20e:2eff:fe2a:a190%rl1 prefixlen 64 scopeid 0x2 pflog0: flags=141 mtu 33224 pfsync0: flags=0<> mtu 2020 enc0: flags=0<> mtu 1536 bridge0: flags=41 mtu 1500
Re: Keep state + bridge weirdness
On Jun 3, 2005, at 6:19 PM, Kelley Reynolds wrote: Having an odd problem... a bridge configured such that one of the interfaces has an IP works fantastically, until pf is enabled with the following rule (and only the following rule) pass out keep state then repeatably, things start to break. Now, when FTPing from one machine to another (whether they are both on the inside of the bridge or not), the transfer will stop after 96k. Every time. If I take off the keep state rule, the transfer will work just fine. Now, on the bottom of 'man bridge', it says that a bridge should only keep state on one interface, so I tried lots of variations of the keep state rule to limit it to one interface, incoming, outgoing, didn't matter. This is on OpenBSD 3.7 with two rl NICs, but this problem also occurred on 3.6. Any ideas? Not until you post the output of "ifconfig -A" and your /etc/pf.conf. -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
Keep state + bridge weirdness
Having an odd problem... a bridge configured such that one of the interfaces has an IP works fantastically, until pf is enabled with the following rule (and only the following rule) pass out keep state then repeatably, things start to break. Now, when FTPing from one machine to another (whether they are both on the inside of the bridge or not), the transfer will stop after 96k. Every time. If I take off the keep state rule, the transfer will work just fine. Now, on the bottom of 'man bridge', it says that a bridge should only keep state on one interface, so I tried lots of variations of the keep state rule to limit it to one interface, incoming, outgoing, didn't matter. This is on OpenBSD 3.7 with two rl NICs, but this problem also occurred on 3.6. Any ideas? Kelley Reynolds President Inside Systems, Inc.
Re: Still no answer on my bridge question -- resolved
Russell Fulton <[EMAIL PROTECTED]> writes: > Yet another illustration of the rule that one should post config files > when asking questions. simply exposing your rule set to a fresh set of eyes sometimes has wonderful problem solving capability. seriously, the real risk of embarrasment along the lines of "now what on g*d's green earth are you doing that for?" is a lot less than you think. Posting your config along with your problem description is always good. Obfuscate if you have to. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
Re: Still no answer on my bridge question -- resolved
On Thu, 2005-04-07 at 12:58 +1200, Russell Fulton wrote: > I am seeing packets being dropped by pf that should not traverse the > bridge at all (i.e. packets between hosts that are on the same side of > the bridge). After a little thought I came to the conclusion that this > is quite plausible since the filtering is taking place on the interface > closest to the affected hosts and the packets are hitting pf before they > get to the bridging logic. Thanks to those who clarified the way bridge and pf interact and to Camiel Dobbelaar who suggested some useful diagnostics in private email. I now know what is going on. A while ago we were having some issues with our two pf/bridges interacting with our cisco switches, the network folk got these partly resolved by turning learning off on the bridges, so now they are simply flooding everything back and forth -- which is exactly what I had observed. Sigh... Thanks again and apologies for bothering the list with something that should have been sorted out locally. Yet another illustration of the rule that one should post config files when asking questions. If I had done that I would have noticed that learning had been turned off and solved the problem then and there. Russell -- Russell Fulton, Information Security Officer, The University of Auckland New Zealand smime.p7s Description: S/MIME cryptographic signature
Re: Still no answer on my bridge question
Thanks Sean! On Wed, 2005-04-06 at 19:36 -0700, Sean Kamath wrote: > [In a message on Thu, 07 Apr 2005 12:58:22 +1200, > Russell Fulton wrote:] > >Hi, > > Earlier I posted a note here asking about the order of processing > >incoming packets on a bridge with pf. I would really like to know if > >there is something wrong with our set up or if this is expected > >behaviour. > > > >I am seeing packets being dropped by pf that should not traverse the > >bridge at all (i.e. packets between hosts that are on the same side of > >the bridge). After a little thought I came to the conclusion that this > >is quite plausible since the filtering is taking place on the interface > >closest to the affected hosts and the packets are hitting pf before they > >get to the bridging logic. > > What do you mean "packets being dropped by pf that should not traverse > the bridge at all"? Some clarity would help here. > the addresses of the packets being dropped are both on the same side of the bridge and therefore the packets should not traverse the bridge. host 1 host2 | | | | +-+-+ | | bridge | | +---- rest of network I am seeing packets between host1 and host2 being dropped on the bridge, filtering is taking place on the interface closest to host1 and host2. Russell smime.p7s Description: S/MIME cryptographic signature
RE: Still no answer on my bridge question
Hi Russell, When I was looking for more information regarding pf + altq I also ask for documents describing packets processing and I got the following links: http://www.redshift.com/~ray/network/packet.gif http://mniam.net/pf/pf.png Hope this helps, Benjamin Constant TI Automotive > -Original Message- > From: Russell Fulton [mailto:[EMAIL PROTECTED] > Sent: jeudi 7 avril 2005 2:58 > To: pf@benzedrine.cx > Subject: Still no answer on my bridge question > > Hi, > Earlier I posted a note here asking about the order of > processing incoming packets on a bridge with pf. I would > really like to know if there is something wrong with our set > up or if this is expected behaviour. > > I am seeing packets being dropped by pf that should not > traverse the bridge at all (i.e. packets between hosts that > are on the same side of the bridge). After a little thought > I came to the conclusion that this is quite plausible since > the filtering is taking place on the interface closest to the > affected hosts and the packets are hitting pf before they get > to the bridging logic. > > I want to know if this conclusion is correct or do I have a > problem that should be investigated. > > BTW I have also spent some time looking for docs that > describe exact order of processing of packets but could not > find anything useful. > > Russell. > > The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. This communication is from TI Automotive.
Re: Still no answer on my bridge question
On Apr 6, 2005 5:58 PM, Russell Fulton <[EMAIL PROTECTED]> wrote: > BTW I have also spent some time looking for docs that describe exact > order of processing of packets but could not find anything useful. #man bridge 4 The algorithm works as follows by default, but can be modified via ioctl(2) or the utility brconfig(8). When a frame comes in, the origin segment and the source address are recorded. If the bridge has no knowl- edge about where the destination is to be found, the bridge will forward the frame to all attached segments. If the destination is known to be on a different segment from its origin, the bridge will forward the packet only to the destination segment. If the destination is on the same seg- ment as the origin segment, the bridge will drop the packet because the receiver has already had a chance to see the frame. Before forwarding a frame, the bridge will check to see if the packet contains an ip(4) or ip6(4) datagram; if so, the datagram is run through the pf(4) interface so that it can be filtered. Hopefully that helps, it seems to describe exactly what you were asking. -- Jon Simola Systems Administrator ABC Communications
Re: Still no answer on my bridge question
On Thu, 7 Apr 2005, Russell Fulton wrote: > I am seeing packets being dropped by pf that should not traverse the > bridge at all (i.e. packets between hosts that are on the same side of > the bridge). After a little thought I came to the conclusion that this > is quite plausible since the filtering is taking place on the interface > closest to the affected hosts and the packets are hitting pf before they > get to the bridging logic. No, bridging comes first. And yes, the packet _should_ be dropped when the destination interface (according to the bridgecache) is the same as the source interface of the packet.
Re: Still no answer on my bridge question
[In a message on Thu, 07 Apr 2005 12:58:22 +1200, Russell Fulton wrote:] >Hi, > Earlier I posted a note here asking about the order of processing >incoming packets on a bridge with pf. I would really like to know if >there is something wrong with our set up or if this is expected >behaviour. > >I am seeing packets being dropped by pf that should not traverse the >bridge at all (i.e. packets between hosts that are on the same side of >the bridge). After a little thought I came to the conclusion that this >is quite plausible since the filtering is taking place on the interface >closest to the affected hosts and the packets are hitting pf before they >get to the bridging logic. What do you mean "packets being dropped by pf that should not traverse the bridge at all"? Some clarity would help here. Are you saying: (host 1, host 2) <> (int_1 OBSD Box int_2) <-> (other hosts) And that packes from host 1 to host 2 (and vice versa) are showing as being dropped on int_2? If so, outbound? By a block rule? Topology and a pf.conf file will get you more help. . . >I want to know if this conclusion is correct or do I have a problem that >should be investigated. > >BTW I have also spent some time looking for docs that describe exact >order of processing of packets but could not find anything useful. Try the list archives. This came over the list on March 17: http://mniam.net/pf/pf.png Sean
Still no answer on my bridge question
Hi, Earlier I posted a note here asking about the order of processing incoming packets on a bridge with pf. I would really like to know if there is something wrong with our set up or if this is expected behaviour. I am seeing packets being dropped by pf that should not traverse the bridge at all (i.e. packets between hosts that are on the same side of the bridge). After a little thought I came to the conclusion that this is quite plausible since the filtering is taking place on the interface closest to the affected hosts and the packets are hitting pf before they get to the bridging logic. I want to know if this conclusion is correct or do I have a problem that should be investigated. BTW I have also spent some time looking for docs that describe exact order of processing of packets but could not find anything useful. Russell. smime.p7s Description: S/MIME cryptographic signature
Re: lan-lan bridge filtering with nat possible ?
On Wed, Mar 23, 2005 at 11:17:28PM +0100, fabien.misto wrote: > the bridge filtering continues to work, but not the nat. > I don't know if it's possible. No, translation (nat, rdr) doesn't generally work on pure bridges. The reason for that is on ethernet level, the way IP and MAC addresses relate, and how things break when pf just replaces IP addresses. Daniel
lan-lan bridge filtering with nat possible ?
Hi, I try to do do a lan lan bridge filtering but I need to have nat too. Explanations: I protect my lab from the rest of the network with a bridge filtering.(protection from virus using tcp port) The both networks are in the same network range.I can't change it. I did a lan lan bridge filtering with OpensBSD 3.5 who uses two network cards. All works fine. But, I have only one ip adress authorized on the router to go on internet. I add the nat command in pf.conf to translate all lab adresses to the autorized address. The nat works,but in this case, the externals ip adresses (lan 1 in the draw) of my lab haven't access at all of my lab as define before in the pf rules. I can't use the rdr in pf.conf because the majority of machine in my lab must be parameter by internet browser on port 80. I install two other network cards to build a second bridge on the same PC. the function of this second bridge should to run only the nat process. I wrotte the nat rules in the same pf.conf file. but it doesn't work. the bridge filtering continues to work, but not the nat. I don't know if it's possible. All comment will be apreciate. Thanks (internet)---[router]---(LAN1)---[PC-CARD-1]---(bridge1)---[PC-CARD-1]-- (LAB) | | --[PC-CARD-2]---(bridge2)---[PC-CARD-1]---
Re: OBSD Bridge Help
This looks like a rather complicated setup, so I think it would be useful to ask, what did the last working setup look like? A couple of things which strike me as odd are - the RFC1918 table looks to me like it includes rather more than the rfc1918 addresses the bad tcp flags section contains quite a number of permutations which may or may not be tripping you up, others which may be redundant you have a quick rule which I think would block traffic from the internal network to the world (block out log quick on $ext_if from ! $ext_if to any) My advice would be to roll back to the last version which was able to pass at least some traffic, then introduce rules one at a time from there, testing each change. That way you will be in a much better position to see what breaks, if it does. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
OBSD Bridge Help
Hello:
Can someone look and see what I have done wrong with
my pf.conf rules. I gathered alot of info from
multiple sites but I can't connect out from my
nat/dhcp router. I have not setup the fw/vpn server
yet. My setup is like:
Internet--Cable Modem---Bridge---Switch---nat/dhcp--
router---FW/VPN---Internal
1. The cable modem has an public ip (xxx.xxx.xxx.121)
2. I have three interfaces on the bridge with one ip
(192.168.1.100) as a management.
3. The servers on the switch have public ips
(xxx.xxx.xxx.123, xxx.xxx.xxx.124). They
run www, mail, and dns
4. The nat/dhcp router is a linksys router with
external ip (xxx.xxx.xxx.122) and
internal ip (192.168.1.1).
5. The management interface on the bridge is connected
to the internal port of the
router
6. The firewall/vpn server has external ip
(192.168.1.2) and internal ip (192.168.2.1)
My pf.conf rules are: (Disregard the Table.. It is
formatted right on my system)
#INITIALIZE VARIABLES
Define the Network Interfaces
ext_if="xl0" # Untrusted (from WAN ISP) side
int_if="xl1" # Internal to application servers
mgt_if="fxp0" # Management Interface
loop_if="lo0" # LoopBack Device
all_if="{ xl0, xl1, fxp0, lo0 }"
Tables
table const
{!192.168.0.0/24,0.0.0.0/8,1.0.0.0/8,2.0.0.0/8,5.0.0.0/8,7.0.0.0/8,10.0.0.0/8,23.0.0.0/8,
27.0.0.0/8,31.0.0.0/8,36.0.0.0/8,37.0.0.0/8,39.0.0.0/8,41.0.0.0/8,42.0.0.0/8,49.0.0.0/8,
50.0.0.0/8,58.0.0.0/8,59.0.0.0/8,73.0.0.0/8,74.0.0.0/8,75.0.0.0/8,76.0.0.0/8,77.0.0.0/8,
78.0.0.0/8,79.0.0.0/8,89.0.0.0/8,90.0.0.0/8,91.0.0.0/8,92.0.0.0/8,93.0.0.0/8,94.0.0.0/8,
95.0.0.0/8,96.0.0.0/8,97.0.0.0/8,98.0.0.0/8,99.0.0.0/8,100.0.0.0/8,101.0.0.0/8,
102.0.0.0/8,103.0.0.0/8,104.0.0.0/8,105.0.0.0/8,106.0.0.0/8,107.0.0.0/8,108.0.0.0/8,
109.0.0.0/8,110.0.0.0/8,111.0.0.0/8,112.0.0.0/8,113.0.0.0/8,114.0.0.0/8,115.0.0.0/8,
116.0.0.0/8,117.0.0.0/8,118.0.0.0/8,119.0.0.0/8,120.0.0.0/8,121.0.0.0/8,122.0.0.0/8,
123.0.0.0/8,124.0.0.0/8,125.0.0.0/8,126.0.0.0/8,127.0.0.0/8,169.254.0.0/16,
172.16.0.0/12,173.0.0.0/8,174.0.0.0/8,175.0.0.0/8,176.0.0.0/8,177.0.0.0/8,178.0.0.0/8,
179.0.0.0/8,180.0.0.0/8,181.0.0.0/8,182.0.0.0/8,183.0.0.0/8,184.0.0.0/8,185.0.0.0/8,
186.0.0.0/8,187.0.0.0/8,189.0.0.0/8,190.0.0.0/8,192.0.2.0/24,192.168.0.0/16,
197.0.0.0/8,198.18.0.0/15,223.0.0.0/8,224.0.0.0/3,255.255.255.255/32}
OPTIONS
set require-order yes
set block-policy return
set optimization normal
set loginterface $ext_if
Public Services
# -
# WWW : Web Server
# -
web_servers="{ xxx.xxx.xxx.123, xxx.xxx.xxx.124}"
web_ports="{ 80, 443, 20, 21, 8080, 8443, 55000, >
49151 }"
web_proto="{ tcp, udp }"
# -
# DNS : Public access resolvers
# -
dns_servers="{ xxx.xxx.xxx.123, xxx.xxx.xxx.124 }"
dns_ports="{ 53 }"
dns_proto="{ tcp, udp }"
# -
# MAIL : Public mail server
# -
mx_servers="{ xxx.xxx.xxx.123, xxx.xxx.xxx.124 }"
mx_ports="{ 80, 143, 443, 25, 110, 943, 995 }"
mx_proto="{ tcp }"
# -
# SSH : Allow remote login
# -
ssh_servers="{ xxx.xxx.xxx.123, xxx.xxx.xxx.124,
xxx.xxx.xxx.125, xxx.xxx.xxx.126, \ 192.168.1/24,
192.168.2/24 }"
ssh_ports="{ 22 }"
ssh_proto="{ tcp }"
# --
# Rsync : Allow rsync to inside
# --
rsync_ports="{ 873 }"
rsync_proto="{ tcp, udp }"
# -
# SQL : MySQL
# -
sql_servers=""
sql_ports="{ 3306 }"
sql_proto=""
# -
# LDAP : Future Use
# -
ldp_servers=""
ldp_ports=""
ldp_proto=""
Illegal Ports
illegal_ports="{ 67, 68, 135, 137, 138, 139, 161, 427,
1433, 1434, 3389 }"
START FILTER RULES
Clean up fragmented and abnormal packets
scrub on $ext_if all random-id min-ttl 255 max-mss
1492 fragment reassemble
#
#
pass quick on $loop_if all
antispoof log for $all_if
# silently drop broadcasts cable modem noise
block in quick on $ext_if from any to 255.255.255.255
# Block bad tcp flags from malicious people and nmap
scans
block in log quick on $ext_if proto tcp from any to
any flags /S
block in log quick on $ext_if proto tcp from any to
any flags /SFRA
block in log quick on $ext_if proto tcp from any to
any flags /SFRAU
block in log quick on $ext_if proto tcp from any to
any flags A/A
block in log quick on $ext_if proto tcp from any to
any flags F/SFRA
block in log quick on $ext_if proto tcp from any to
any flags U/SFRAU
block in log quick on $ext_if proto tcp from any to
any flags SF/SF
block in log quick on $ext_if proto tcp from any to
any flags SF/SFRA
block in log quick on $ext_if proto tcp from any to
any flags SR/SR
bl
Re: Openbsd Bridge with IP addess. SSH access
On Mar 21, 2005, at 10:51 AM, Keith wrote:
Hi, I have basicaly setup a transparent bridge with two nic's as shown
below.
---Router---[$ext_if - FW - $int_if]---[Switch][Servers
This works fine but I have given the internal nic a public IP address
but am having trouble working out how to restict access to the FW via
SSH on that NIC.
i thought that I could setup a default block policy then allow access
to the SSH Server from certain IP addresses.
Can someone help ?
You can filter on IP, but if you intend to prevent external access that
way, just remember that IP's are spoofable. It's certainly not a bad
place to start, though, and routing limits the physical domain of where
your spoofers may reside and still get packet responses. Using a
bridge, it's one of your few options. You can also require "flags
S/SA," and keep state on the connections.
What sort of access restrictions did you want to impose?
A few things to note:
traffic that addresses the bridge won't get tagged with brconfig tag
rules
(it's not being bridged).
traffic that addresses the bridge won't necessarily appear on the
correct
interface for your pf rules ("borken by design," see:
http://www.sigmasoft.com/~openbsd/archive/openbsd-misc/200502/
msg01916.html
and the rest of the thread.).
JMF
Openbsd Bridge with IP addess. SSH access
Hi, I have basicaly setup a transparent bridge with two nic's as shown below. ---Router---[$ext_if - FW - $int_if]---[Switch][Servers This works fine but I have given the internal nic a public IP address but am having trouble working out how to restict access to the FW via SSH on that NIC. i thought that I could setup a default block policy then allow access to the SSH Server from certain IP addresses. Can someone help ? also I have noticed that i cant see SSH connections into the firewall via pftop. Please help... Cheers Keith
Re: PF, Bridge, and IP on bridged interface [more]
On Mar 15, 2005, at 12:20 AM, Sean Kamath wrote: [In a message on Wed, 02 Mar 2005 05:34:20 GMT, [EMAIL PROTECTED] wrote:] In my case, I'm running a SS20 with le* interfaces, which means that all interfaces use the same ethernet address. I'm curious, doesn't setting local-mac-address? to true doesn't work with LE's? Only HME's and newer? Actually, I guess only quad HME's and newer, according to: http://www.barbary.com/cookbooks/macaddress.html Right. One would think it, in theory, possible. Obviously, the card is getting its ethernet address from the OF PROM. I don't know how programmable OF is... I would think some forth code might be able to change the bahavior to hand out incremental ethernet addresses as they are requested, but if it were possible, someone would probably already have done it. A replacement boot PROM might do it, but I don't know one exists that would do such a thing. The later NIC's simply had their own ethernet addresses built-in. So, I guess that leaves the question, can one change the ethernet address of a NIC with ifconfig on OpenBSD? My 3.5 box doesn't seem to allow it. . . Before securelevel is changed, you can tell the kernel that an interface has a different ethernet address than it really has, but this particular hardware overwrites outgoing frames. I presume this could cause all sorts of trouble. JMF
Re: PF, Bridge, and IP on bridged interface [more]
On Tuesday 15 March 2005 12:19, Henning Brauer wrote: > > So, I guess that leaves the question, can one change the ethernet > > address of a NIC with ifconfig on OpenBSD? > > no. Yet. http://marc.theaimsgroup.com/?l=openbsd-tech&m=111073781926839&w=2
Re: PF, Bridge, and IP on bridged interface [more]
* Sean Kamath <[EMAIL PROTECTED]> [2005-03-15 06:40]: > So, I guess that leaves the question, can one change the ethernet > address of a NIC with ifconfig on OpenBSD? no. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: PF, Bridge, and IP on bridged interface [more]
[In a message on Wed, 02 Mar 2005 05:34:20 GMT, [EMAIL PROTECTED] wrote:] >In my case, I'm running a SS20 with le* interfaces, which means that >all interfaces use the same ethernet address. I'm curious, doesn't setting local-mac-address? to true doesn't work with LE's? Only HME's and newer? Actually, I guess only quad HME's and newer, according to: http://www.barbary.com/cookbooks/macaddress.html So, I guess that leaves the question, can one change the ethernet address of a NIC with ifconfig on OpenBSD? My 3.5 box doesn't seem to allow it. . . Sean
Re: PF, Bridge, and IP on bridged interface [more]
Trevor Talbot wrote: > Apologies for not reading everything you've posted, but this thread may > provide the clue you're looking for: > http://www.benzedrine.cx/pf/msg03238.html That thread is, without the extensive quoting of rules and dump logs, approximately word-for-word what I've been doing. :-) No, it wasn't headers out of synch for me. This happened in stock 3.5, stock 3.6, and -current as of last week. Many people have been of great help, including one Camiel Dobbelaar, whose patch to if_bridge.c (for a VLAN-related, but similar, issue) I found on the web, and modified. I solved about half of the problem, and found that it was good enough for me. That bridge tagging doesn't work, I figured out the hard way. :-) Essentially, as I understand it: when bridge_input() receives a unicast frame, it searches the list of bridge interfaces for the interface with matching ethernet address from the frame. In my case, I'm running a SS20 with le* interfaces, which means that all interfaces use the same ethernet address. Since le2 was added to the bridge last, ALL inbound traffic showed up in PF rules as coming in on le2. The patch I made checks first to see if the destination address is the same as the interface passed to bridge_input(), it disables rewriting m_pkthdr.rcvif. Viola! All traffic across the bridge still functions properly, but frames destined FOR the bridgewill now match the appropriate "in on le*" rule. Still, all of my outbound traffic originating from the OBSD box shows up as out on le0 (the interface with the IP). I figure that since le2 has no IP address, it CAN'T be a route. (Also, I didn't patch the broadcast/multicast frame section in bridge_input, so those still might show up in PF as being in on the wrong interface. ARP being broadcast, and arriving first, this might have something to do with the weird outbound route, though, according to the problems I was having with INbound unicast, it should see those all on le2, which wouldn't explan an outbound route of le0.) However, I'm not too concerned about this. (1) The reason I'm using a bridge in the first place, and not separate subnets, is to PASS broad/multicast packets. (2) If I can block IN on all interfaces separately, the only reason I'd have to block OUT on all interfaces separately is if I did not trust traffic from the OBSD box. The only reason I can think for not trusting that would be a compromised server, and at that point, PF rules are useless. For the patch, see: http://www.sigmasoft.com/~openbsd/archive/openbsd-misc/200502/msg01916.html Use at your own risk. I have no idea if this will break countless other things. FWIW, it doesn't seem to have broken anything else that I happen to be using. > Assuming I understand everything correctly, you won't have this problem > in a pure bridging scenario -- where the IP destination or gateway is > not this machine. The problem would still be there, you'd just never see it, because you wouldn't be looking for it, as there would be no way to send frames TO the bridge machine. :-) The only reason I (and Torsten) have this problem is because we want the bridge machine to be directly addressable. Also, FWIW, I've been informed by certain parties that "it's a bridge;" this is "100% normal." I don't care. I don't like it; I changed it; and I'm happy. Hooray for open source. I, too, think it's brain-dead that the [stock] bridge interface makes it impossible to tell where an inbound frame came in on. As both Torsten and I have said, the physical interface of incidence is the only property of a frame that is 100% unspoofable. If that inability qualifies the BSD bridge as an "ugly hack," then I agree with you. JMF
Re: PF, Bridge, and IP on bridged interface [more]
On Friday, Feb 18, 2005, at 07:07 US/Pacific, Jim Fron wrote: As I mentioned before, using tcpdump on le0 and le2 shows traffic arriving and departing on the correct interfaces all of the time, regardless of bridge state. However, traffic appearing in pflog as matching rules from the "wrong" interface is due to the bridge: $ sudo brconfig bridge0 down $ sudo tcpdump -netttvvv -i pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0 Feb 18 09:51:51.949840 rule 2/0(match): pass in on le0: 192.168.1.9 > 192.168.1.1: icmp: echo request (id:19bc seq:0) (ttl 64, id 30421) Feb 18 09:51:51.950030 rule 4/0(match): pass out on le0: 192.168.1.1 > 192.168.1.9: icmp: echo reply (id:19bc seq:0) (ttl 255, id 25154) $ sudo brconfig bridge0 up $ sudo tcpdump -netttvvv -i pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0 Feb 18 09:52:29.459668 rule 3/0(match): pass in on le2: 192.168.1.9 > 192.168.1.1: icmp: echo request (id:19bd seq:0) (ttl 64, id 30487) Feb 18 09:52:29.459838 rule 4/0(match): pass out on le0: 192.168.1.1 > 192.168.1.9: icmp: echo reply (id:19bd seq:0) (ttl 255, id 21188) Apologies for not reading everything you've posted, but this thread may provide the clue you're looking for: http://www.benzedrine.cx/pf/msg03238.html Assuming I understand everything correctly, you won't have this problem in a pure bridging scenario -- where the IP destination or gateway is not this machine.
Re: PF, Bridge, and IP on bridged interface [more]
As I mentioned before, using tcpdump on le0 and le2 shows traffic arriving and departing on the correct interfaces all of the time, regardless of bridge state. However, traffic appearing in pflog as matching rules from the "wrong" interface is due to the bridge: $ sudo brconfig bridge0 down $ sudo tcpdump -netttvvv -i pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0 Feb 18 09:51:51.949840 rule 2/0(match): pass in on le0: 192.168.1.9 > 192.168.1.1: icmp: echo request (id:19bc seq:0) (ttl 64, id 30421) Feb 18 09:51:51.950030 rule 4/0(match): pass out on le0: 192.168.1.1 > 192.168.1.9: icmp: echo reply (id:19bc seq:0) (ttl 255, id 25154) $ sudo brconfig bridge0 up $ sudo tcpdump -netttvvv -i pflog0 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0 Feb 18 09:52:29.459668 rule 3/0(match): pass in on le2: 192.168.1.9 > 192.168.1.1: icmp: echo request (id:19bd seq:0) (ttl 64, id 30487) Feb 18 09:52:29.459838 rule 4/0(match): pass out on le0: 192.168.1.1 > 192.168.1.9: icmp: echo reply (id:19bd seq:0) (ttl 255, id 21188) Where: @2 pass in log-all quick on le0 all @3 pass in log-all quick on le2 all @4 pass out log-all quick on le0 all So, back to my earlier questions: is this a bug in bridge? Whether it is or is not, is this behavior determinate -- that is, with the bridge up: inbound traffic from le0 to le2, and vice versa, always matches rules for the correct interfaces inbound traffic from le0 AND le2 to the router always appears to match rules for le2 outbound traffic from the router to le0 AND le2 always appears to match rules for le0 Why? Can I depend on this to always be the case? How do I know which interface it will pick for the 'outbound,' and which it will pick for the 'inbound'? Is that a function of which interface has the IP assigned? Is it a function of the order in which they were added to the bridge? Is it a function of boot-time discovery order? Interface number? Etc.? Thanks, Jim
Re: PF, Bridge, and IP on bridged interface [more]
I'm copying both pf and [EMAIL PROTECTED] It's looking as though I may
have to take this to a Sparc specific forum, though. Unless someone
can offer an explanation of what I'm seeing, I'm starting to suspect
Sparc/SBUS-specific programming here.
1b. bridge (4), and all of the literature I can find online says
that frames on the bridge will pass through pf twice.
"Bridged frames pass through pf(4) twice. They can be filtered
on any interface, in both directions."
-> They do not appear to do so. They appear to pass through pf only
once.
That is, they pass in once and out once, exactly as they do when
routing between two Subnets in an unbridged configuration.
That sentence is meant to explain exactly that there's no difference
between bridging and IP forwarding regarding pf, that pf sees the same
packet twice, once incoming on an interface, once outgoing on another
interface, that's twice.
The reason why it's mentioned is that some OS / packet filter
combinations don't work this way.
Ah. That makes sense, then. I was confused, probably by the fact that
my other problem makes it appear as though the packets are going in and
out on both le0 and le2...
2b. traffic from the LAN to the router appears to come from the
wrong interface
I suspect that if I can solve this one, it will go a great way toward
explaining my issues with bridge tagging...
You might want to run tcpdump -nvvvei on the two interfaces
directly and check the MAC addresses printed. pf will see the same
frames on the same interfaces as you see with tcpdump on the
interfaces.
If a frame really comes in on the wrong interfaces, and tcpdump shows
that, you can be pretty sure that, for whatever reason, the frame
really
did arrive on that interface. The explanation must be found somewhere
in
your network or cabling.
If the frames are coming in on the wrong physical device, then its a
Sun SBUS problem, because it's not happening OUTSIDE the box. le2 has
cat5 running to a hub. That hub currently, for testing purposes, has
only 2 cables connected to it: the one that goes to le2, and the one
that is connected to a laptop I'm using for test purposes. The
ethernet card is this laptop's ONLY interface (it has no wireless), so
there's no way these packets are getting routed through by some other
means...
sudo tcpdump -nvvvei le0 icmp
08:13:01.713967 0:a:95:79:cb:8a 8:0:20:77:a4:79 0800 98: 192.168.1.9 >
192.168.1.1: icmp: echo request (id:124b seq:7) (ttl 64, id 12065)
08:13:01.714362 8:0:20:77:a4:79 0:a:95:79:cb:8a 0800 98: 192.168.1.1 >
192.168.1.9: icmp: echo reply (id:124b seq:7) (ttl 255, id 6392)
08:13:02.714094 0:a:95:79:cb:8a 8:0:20:77:a4:79 0800 98: 192.168.1.9 >
192.168.1.1: icmp: echo request (id:124b seq:8) (ttl 64, id 12067)
08:13:02.714410 8:0:20:77:a4:79 0:a:95:79:cb:8a 0800 98: 192.168.1.1 >
192.168.1.9: icmp: echo reply (id:124b seq:8) (ttl 255, id 23496)
sudo tcpdump -netttvvv -r /var/log/pflog
Feb 17 08:13:01.714093 rule 3/0(match): pass in on le2: 192.168.1.9 >
192.168.1.1: icmp: echo request (id:124b seq:7) (ttl 64, id 12065)
Feb 17 08:13:01.714291 rule 4/0(match): pass out on le0: 192.168.1.1 >
192.168.1.9: icmp: echo reply (id:124b seq:7) (ttl 255, id 6392)
Feb 17 08:13:02.714210 rule 3/0(match): pass in on le2: 192.168.1.9 >
192.168.1.1: icmp: echo request (id:124b seq:8) (ttl 64, id 12067)
Feb 17 08:13:02.714339 rule 4/0(match): pass out on le0: 192.168.1.1 >
192.168.1.9: icmp: echo reply (id:124b seq:8) (ttl 255, id 23496)
Yeah, a live tcpdump shows the packets on the correct interface. pflog
shows them being caught by rules for the wrong interface.
As for outgoing packets from the bridge itself, they should pass out
through the appropriate interface in both cases, assuming the bridge
has
learned that the destination MAC address is reachable through a
particular interface. When you first ping an unknown destination, the
stack will do an ARP lookup to find the destination MAC address for the
IP address. When the peer replies ARP, the bridge learns which
interface
that MAC address is reachable through, so the first ICMP echo request
will already pass out through the appropriate interface only.
Well, from a live tcpdump, it looks as though it's learned correctly:
$ sudo tcpdump -netttvvvi le0 icmp
tcpdump: listening on le0
Feb 17 08:24:37.390382 8:0:20:77:a4:79 0:a:95:79:cb:8a 0800 98:
192.168.1.1 > 192.168.1.9: icmp: echo request (id:3a42 seq:14) (ttl
255, id 22077)
Feb 17 08:24:37.390795 0:a:95:79:cb:8a 8:0:20:77:a4:79 0800 98:
192.168.1.9 > 192.168.1.1: icmp: echo reply (id:3a42 seq:14) (ttl 64,
id 14048)
Feb 17 08:24:38.400368 8:0:20:77:a4:79 0:a:95:79:cb:8a 0800 98:
192.168.1.1 > 192.168.1.9: icmp: echo request (id:3a42 seq:15) (ttl
255, id 27704)
Feb 17 08:24:38.400775 0:a:95:79:cb:8a 8:0:20:77:a4:79 0800 98:
192.168.1.
Re: PF, Bridge, and IP on bridged interface [more]
On Wed, Feb 16, 2005 at 10:51:48PM -0500, Jim Fron wrote: > Okay, I can get my bridge and pf rules working if I need to, but > I'd still like to understand WHY they work they way they do. So > I ran some test cases. > 1b. bridge (4), and all of the literature I can find online says > that frames on the bridge will pass through pf twice. > "Bridged frames pass through pf(4) twice. They can be filtered > on any interface, in both directions." > > -> They do not appear to do so. They appear to pass through pf only > once. > That is, they pass in once and out once, exactly as they do when > routing between two Subnets in an unbridged configuration. Why? > Is the documentation wrong? Are there frames that are not showing > up in my pflog, despite all rules being log-all? For this > "dual pass" through pf, does it only make a second pass if it > has not found a destination? When running these tests, I first > did a `brconfig bridge0 flushall` in the hopes of eliminating such > a scenario. That sentence is meant to explain exactly that there's no difference between bridging and IP forwarding regarding pf, that pf sees the same packet twice, once incoming on an interface, once outgoing on another interface, that's twice. The reason why it's mentioned is that some OS / packet filter combinations don't work this way. For instance, on older OpenBSD releases IPFilter (in bridged setups) would only see packets coming in on the first interface (but not again outgoing on the other), so people learned to write their rulesets with this in mind, and only filtered incoming. If you assumed pf wouldn't filter packets outgoing (again), and used a default block policy, the pf bridge possibly wouldn't work. That's what this sentence in the documentation is supposed to make clear. > 2b. traffic from the LAN to the router appears to come from the > wrong interface I don't know why you're seeing this. You might have some cabling problem that explains why packets pass in on the wrong interface. I have a similar setup for my wireless access point running pf, one sis(4) interface to the LAN with an IP address assigned, and one wi(4) interface without an address. I can ping through the bridge from either side, or ping from and to the bridge itself to/from either side, and only see packets on the expected interfaces. It doesn't matter at all which interface I assign the address to. You might want to run tcpdump -nvvvei on the two interfaces directly and check the MAC addresses printed. pf will see the same frames on the same interfaces as you see with tcpdump on the interfaces. If a frame really comes in on the wrong interfaces, and tcpdump shows that, you can be pretty sure that, for whatever reason, the frame really did arrive on that interface. The explanation must be found somewhere in your network or cabling. As for outgoing packets from the bridge itself, they should pass out through the appropriate interface in both cases, assuming the bridge has learned that the destination MAC address is reachable through a particular interface. When you first ping an unknown destination, the stack will do an ARP lookup to find the destination MAC address for the IP address. When the peer replies ARP, the bridge learns which interface that MAC address is reachable through, so the first ICMP echo request will already pass out through the appropriate interface only. In short, things should be pretty similiar to IP forwarding. Note that 'log-all' is only meaningful when you create state (otherwise 'log' is sufficient, as each packet causes evaluation of the ruleset). If you do create state, all packets related to one state get logged with the rule number that created the state. Subsequent packets might not be passing through the same interface as the first packet (if not using if-bound states). Running tcpdump on the real interface might clear things up. Daniel
PF, Bridge, and IP on bridged interface [more]
Okay, I can get my bridge and pf rules working if I need to, but I'd still like to understand WHY they work they way they do. So I ran some test cases. My configuration is this: OpenBSD/Sparc (SS20). I have one external interface, and two internal interfaces. There's NAT to the external, but that's working flawlessly, so we'll leave that out of the equation for now. The two internal interfaces are bridged, and I have various pf rules restricting what can and cannot pass between them (as well as between the internal and external world). However, I'm not entirely clear on what's going on... where the bridge acts in the general process flow, whether bridge rules act before or after frames are copied to the bridged interfaces, exactly how the bridge tagging rules work, etc. What I'm looking to do is construct something like the process flow diagrams at: http://mniam.net/pf/pf.png and http://homepage.mac.com/quension/pf/flow.png except with a bridge in the model. So I decided to run some test cases with rule sets that pass and log everything. Now that I have some data, and I've looked it over, I have a few questions. So, here's my first, simple case: $ cat /etc/bridgename.bridge0 add le0 add le2 blocknonip le0 blocknonip le2 rule pass in on le0 tag t_lan rule pass in on le2 tag t_wap up $ cat /etc/hostname.le0 inet 192.168.1.1 255.255.255.0 NONE $ cat /etc/hostname.le2 up pf rules: @0 pass out quick on lo0 all @1 pass in quick on lo0 all @2 pass in log-all quick on le0 all @3 pass in log-all quick on le2 all @4 pass out log-all quick on le0 all @5 pass out log-all quick on le2 all Router: 192.168.1.1 LAN client: 192.168.1.9 WLAN client: 192.168.1.130 And I proceeded to execute some pings, from the console of each machine. LAN machine pings router: Passes in on le2 (incorrect), reply passes out on le0 (correct) Feb 16 08:28:43.378979 rule 3/0(match): pass in on le2: 192.168.1.9 > 192.168.1.1 : icmp: echo request (id:0f5a seq:0) (ttl 64, id 3081) Feb 16 08:28:43.379197 rule 4/0(match): pass out on le0: 192.168.1.1 > 192.168.1.9 : icmp: echo reply (id:0f5a seq:0) (ttl 255, id 36469) LAN machine pings WLAN machine: Request passes in on le0 (correct) first, then out on le2 (correct) Reply passes in on le2 (correct) first, then out on le0 (correct) Feb 16 08:28:54.881680 rule 2/0(match): pass in on le0: 192.168.1.9 > 192.168.1.130: icmp: echo request (id:0f5b seq:0) (ttl 64, id 3108, bad cksum 0!) Feb 16 08:28:54.881737 rule 5/0(match): pass out on le2: 192.168.1.9 > 192.168.1.130: icmp: echo request (id:0f5b seq:0) (ttl 64, id 3108) Feb 16 08:28:54.882440 rule 3/0(match): pass in on le2: 192.168.1.130 > 192.168.1.9 : icmp: echo reply (id:0f5b seq:0) (ttl 64, id 48170, bad cksum 0!) Feb 16 08:28:54.882487 rule 4/0(match): pass out on le0: 192.168.1.130 > 192.168.1.9 : icmp: echo reply (id:0f5b seq:0) (ttl 64, id 48170) WLAN machine pings router: Passes in on le2 (correct), reply passes out on le0 (incorrect) Feb 16 08:29:22.925161 rule 3/0(match): pass in on le2: 192.168.1.130 > 192.168.1.1 : icmp: echo request (id:028b seq:0) (ttl 64, id 48190) Feb 16 08:29:22.925292 rule 4/0(match): pass out on le0: 192.168.1.1 > 192.168.1.130: icmp: echo reply (id:028b seq:0) (ttl 255, id 53634) WLAN machine pings LAN machine: Request passes in on le2 (correct) first, then out on le0 (correct) Reply passes in on le0 (correct) first, then out on le2 (correct) Feb 16 08:29:32.830865 rule 3/0(match): pass in on le2: 192.168.1.130 > 192.168.1.9 : icmp: echo request (id:028c seq:0) (ttl 64, id 48200, bad cksum 0!) Feb 16 08:29:32.830917 rule 4/0(match): pass out on le0: 192.168.1.130 > 192.168.1.9 : icmp: echo request (id:028c seq:0) (ttl 64, id 48200) Feb 16 08:29:32.831474 rule 2/0(match): pass in on le0: 192.168.1.9 > 192.168.1.130: icmp: echo reply (id:028c seq:0) (ttl 64, id 3191, bad cksum 0!) Feb 16 08:29:32.831523 rule 5/0(match): pass out on le2: 192.168.1.9 > 192.168.1.130: icmp: echo reply (id:028c seq:0) (ttl 64, id 3191) Router pings LAN machine: Passes out on le0 (correct), reply passes in on le2 (incorrect) Feb 16 08:29:48.837588 rule 4/0(match): pass out on le0: 192.168.1.1 > 192.168.1.9 : icmp: echo request (id:16ee seq:0) (ttl 255, id 62936) Feb 16 08:29:48.838269 rule 3/0(match): pass in on le2: 192.168.1.9 > 192.168.1.1 : icmp: echo reply (id:16ee seq:0) (ttl 64, id 3223) Router pings WLAN machine: Passes out on le0 (incorrect), reply passes in on le2 (correct) Feb 16 08:29:56.494341 rule 4/0(match): pass out on le0: 192.168.1.1 > 192.168.1.130: icmp: echo request (id:7ff8 seq:0) (ttl 255, id 60383) Feb 16 08:29:56.495223 rule 3/0(match): pass in on le2: 192.168.1.130 > 192.168.1.1 : icmp: echo reply (id:7ff8 seq:0) (ttl 64, id 48215) 1a. My pf rules are all lo
Re: ftp throu transparent filtering bridge
On Tue, 23 Nov 2004 11:24:18 +0100 (CET), Roman Marcinek <[EMAIL PROTECTED]> wrote: > Hi Guys, > > an excusse for my question: > > I am relativelly new to the OpenBSD (and PF) though not so the other > firewall/filtering/nating :) Hi Romek! When I was new to PF these two sites helped me a lot! http://www.benzedrine.cx/pf.html http://www.aei.ca/~pmatulis/main_menu.html Good Luck! Kind Regards Siju
Re: ftp throu transparent filtering bridge
Yes, that's true :) ftpsesame really works as said so ... thanks to all :) Romek
Re: ftp throu transparent filtering bridge
Well, it certainly does the job! :) To Roman's initial question though, monitoring ftp connections is really an application layer problem/responsibility. pf is lower level and would need to implement (pretty much) a full protocol layer to monitor ftp. Anyway, there you have it.. check out ftpsesame :) A --- Camiel Dobbelaar <[EMAIL PROTECTED]> wrote: > > > > On Tue, 23 Nov 2004, Roman Marcinek wrote: > >Are there any smarted solutions I haven't found yet? I know that > > > linux's iptables make use of special connection tracking module for > ftp > > to handle that problem but ... is there anything like this for > OpenBSD? > > Ok, let me plug my own program again: > > http://www.sentia.org/ftpsesame > > > Find local movie times and trailers on Yahoo! Movies. http://au.movies.yahoo.com
Re: ftp throu transparent filtering bridge
On Tuesday 23 November 2004 12:50, Camiel Dobbelaar wrote: > On Tue, 23 Nov 2004, Camiel Dobbelaar wrote: > > On Tue, 23 Nov 2004, Roman Marcinek wrote: > > >Are there any smarted solutions I haven't found yet? I know that > > > linux's iptables make use of special connection tracking module for ftp > > > to handle that problem but ... is there anything like this for OpenBSD? > > > > Ok, let me plug my own program again: > > > > http://www.sentia.org/ftpsesame > > Duh, at least get the link right: > > http://www.sentia.org/projects/ftpsesame Heh, happens to the best. Any chance to see a this as a FreeBSD port? Sounds interesting. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpPTUI8jjtXw.pgp Description: PGP signature
Re: ftp throu transparent filtering bridge
Roman Marcinek wrote: Are there any smarted solutions I haven't found yet? I know that linux's iptables make use of special connection tracking module for ftp to handle that problem but ... is there anything like this for OpenBSD? If things like this are solvable shouldn't the solutions find the way to the bridging part of FAQ? I'd suggest so very strongly :) http://www.sentia.org/projects/ftpsesame/ is very interesting on bridges. Moritz
Re: ftp throu transparent filtering bridge
On Tue, 23 Nov 2004, Camiel Dobbelaar wrote: > On Tue, 23 Nov 2004, Roman Marcinek wrote: > >Are there any smarted solutions I haven't found yet? I know that > > linux's iptables make use of special connection tracking module for ftp > > to handle that problem but ... is there anything like this for OpenBSD? > > Ok, let me plug my own program again: > > http://www.sentia.org/ftpsesame Duh, at least get the link right: http://www.sentia.org/projects/ftpsesame Sorry about that.
Re: ftp throu transparent filtering bridge
On Tue, 23 Nov 2004, Roman Marcinek wrote: >Are there any smarted solutions I haven't found yet? I know that > linux's iptables make use of special connection tracking module for ftp > to handle that problem but ... is there anything like this for OpenBSD? Ok, let me plug my own program again: http://www.sentia.org/ftpsesame
Re: ftp throu transparent filtering bridge
Hi,
On Tue, Nov 23, 2004 at 11:24:18AM +0100, Roman Marcinek wrote:
> As the bridge is completely transparent and without ANY IP number on
> any of the two cards I cannot solve my ftp problem via local ftp-proxy
> solution descibed in the documentation. Also setting simple rules like:
>
> pass in quick on $ext_if proto tcp from { $local } to any port = \
> ftp-data flags S/SA keep state
> pass in quick on $ext_if proto tcp from { $local } to any port = \
> ftp flags S/SA keep state
>
> gets mefro a client behind the bridge to the server outside (I even get
> banners/readmes) but any dir/ls gets back to me.
Your solution is good with a transparent bridge PF installation. But be
carefull, it works only with FTP in passive mode (connection form client
to server for ftp_data).
>Are there any smarted solutions I haven't found yet? I know that
> linux's iptables make use of special connection tracking module for ftp
> to handle that problem but ... is there anything like this for OpenBSD?
> If things like this are solvable shouldn't the solutions find the way to
> the bridging part of FAQ? I'd suggest so very strongly :)
No, PF have not application connection tracking (like Iptables
ftp_conntrack). That's why there is an userland ftp-proxy in OpenBSD.
PF devs don't like application (OSI layer 7) connection tracking : for
needs like that, an userland proxy is the solution (according to their
opinion).
A++ Foxy
--
Laurent Cheylus <[EMAIL PROTECTED]> OpenPGP ID 0x5B766EC2
ftp throu transparent filtering bridge
Hi Guys,
an excusse for my question:
I am relativelly new to the OpenBSD (and PF) though not so the other
firewall/filtering/nating :)
Now, few days ago I've set up a transparent bridge on freshly
installed OpenBSD 3.6 (my experience with OpenBSD started with 3.5 used
as a desktop, just to learn the system, then I've just red about PF, not
actually used it). And I did my homework and read some info from OpenBSD
and around. Setting it up was therefore very easy now it's time for
problems.
At first I did it almost completely open from within and almost
completely blocking from without. And it worked like charm. Now I'd like
to get it more blocking also from within, just in case some of my users
(I am at one of the departments at the university) gets too smart and
would like to start bothering others.
One of the valid things (with other ones not problems whatsoever :)
for me is trying to get something from without via ftp but there is some
problem and therefore the question. And I didn't find my answer in other
docs :(
As the bridge is completely transparent and without ANY IP number on
any of the two cards I cannot solve my ftp problem via local ftp-proxy
solution descibed in the documentation. Also setting simple rules like:
pass in quick on $ext_if proto tcp from { $local } to any port = \
ftp-data flags S/SA keep state
pass in quick on $ext_if proto tcp from { $local } to any port = \
ftp flags S/SA keep state
gets mefro a client behind the bridge to the server outside (I even get
banners/readmes) but any dir/ls gets back to me.
Are there any smarted solutions I haven't found yet? I know that
linux's iptables make use of special connection tracking module for ftp
to handle that problem but ... is there anything like this for OpenBSD?
If things like this are solvable shouldn't the solutions find the way to
the bridging part of FAQ? I'd suggest so very strongly :)
Best regards
Romek
pf+altq+bridge : cbq not limiting
Hello, I recently updated the bridge firewall (Sparc64/OpenBSD) from 3.4 to 3.5 (full reinstall). I use it a as a filtering bridge, grouping pf/altq/bridging. I use some cbq queues to shape the traffic. However it seems that the queueing doesn't limit the traffic. I limit on both NICs of the machine (outgoing rules, pass out). But without any changes to pf.conf (it was working well on 3.4), I meet this problem. I labeled the rules to checks if the identification works well and it is the case. If I make some bursting to test, no shaping occurs while a 'pfctl -s queue' shows the right queues and a 'pfctl -vs rules' shows the right rules but too much bytes sent acording to the queue definition. anybody has already seen this? thanks alot. julien
Re: two bridge-questions
On Tue, 21 Sep 2004 08:22:09 +0200, Soleyman Luris <[EMAIL PROTECTED]> wrote: > I'm using OpenBSD 3.6-snap and pf as an "invisible" bridge. > > The bridge is fxp0<->fxp1 > xl0 is configured to be a "admin interface" > fxp1 and xl0 are connected to the inner switch where the other hosts are. There is no advantage to having a separate admin interface if it's on the same segment with your bridge interfaces. I suggest you disable xl0 and assign its IP to fxp0 or fxp1 instead. Then you will be able to admin the machine from either side. If you wish to restrict access to the admin IP, use filter rules. Your setup seems more complex than it needs to be. I don't know if simplifying it will fix either of the problems you are having, but it's worth a try, and your network will be easier to understand which may lead to solving the problems another way. -- Gragnak the Bold
two bridge-questions
I'm using OpenBSD 3.6-snap and pf as an "invisible" bridge. The bridge is fxp0<->fxp1 xl0 is configured to be a "admin interface" fxp1 and xl0 are connected to the inner switch where the other hosts are. The bridge works fine. pf filters fine. But I have two questions: 1. Why can't I ssh directly from the outside to the "admin interface"? I have no pf rules to disallow it. I thought my packets would be bridged and then picked up by the admin interface. ssh:ing to 84.240.56.18 and from there to 84.240.56.17 works fine. Even with pfctl -d it doesn't work to ssh externally directly to 84.240.56.17. 2. Why can't I do redirects? (I've used rdr before in combination with NAT, and there it works) I try to do it like this: rdr on fxp0 inet proto tcp from any to 84.240.56.19 port 25 -> 84.240.56.18 but smtp-traffic to 84.240.56.19 is not redirected. Is there maybe a rdr-trick with bridges? "additional info": $ cat /etc/bridgename.bridge0 add fxp0 add fxp1 -learn fxp0 up $ cat /etc/hostname.fxp0 up $ cat /etc/hostname.fxp1 up $ cat /etc/hostname.xl0 up inet 84.240.56.17 255.255.255.240 NONE
Bridge/nat/rdr problem
I have a Net4501 bridging a cable modem and providing NAT
[Bridged Network] -- (sis2) (sis1) (sis0) - Cable Modem
(no ip) | (cable modem IP)
|
|
(NATed network, 192.168.0.0/24)
What I'm trying to do is get the computers behind the cable modem to get
access to content on the NATed network.
I have a rdr on sis0 which will deflect things from the public IP to a
machine behind the NAT
# HTTP to cesium
rdr on sis0 inet proto {tcp} to port 80 -> 192.168.0.23 port 80
rdr on sis0 inet proto {tcp} to port 443 -> 192.168.0.23 port 443
This doesn't seem to make clients on the sis2 side of the network
capable of accessing content on that IP though. The IPs the cable modem
leases are not at all on the same network (67.174.157.x, 67.174.168.x,
etc all with a 255.255.255.0 netmask). The modem seems to do some
routing of its own, but this may be complicating the matter.
Is it possible to 'steal' traffic on the sis2 interface and push it into
the NATed network?
If so, how?
Thanks for all your help.
Re: pfsync, carp, transparent bridge
I read that "each carp group has a virtual MAC (link layer) address" http://www.countersiege.com/doc/pfsync-carp/ So if you give an ip addres at each bridge, it should work ? And for pfsync, a dedicated network interface with a crossover cable should work too ? Am I wrong ? Sean wrote: Lyle Worthington wrote: Our firewall is ipless, all traffic just runs through it because it is the only way in or out of our network. CARP and pfsync both needs IPs to operate. In pfsync's case, it'll use multicast or a unicast address. For CARP, failover is on a per IP basis and CARP'ed addresses require an address on an existing interface. cheers, Sean
Re: pfsync, carp, transparent bridge
Lyle Worthington wrote: > Our firewall is ipless, all traffic just runs through it because it is > the only way in or out of our network. CARP and pfsync both needs IPs to operate. In pfsync's case, it'll use multicast or a unicast address. For CARP, failover is on a per IP basis and CARP'ed addresses require an address on an existing interface. cheers, Sean
pfsync, carp, transparent bridge
I have found other instances of this question, but never a complete answer on how to do this... Our firewall is ipless, all traffic just runs through it because it is the only way in or out of our network. We have discussed different options but at this time are unable to change our setup. Has anyone gotten this working with pfsync and carp? Does carp/pf control the status of the bridge so whichever firewall is the master the bridge is up, and the other firewall's bridge is down? We are worried about duplicate packets hitting/leaving our network as we would just have a hub from the router to the external interfaces and a hub from the internal interfaces to the network. Thanks, Lyle Worthington
return-icmp-as-dest + bridge: help needed
_icmp & 255, af, r, pd->eh, kif->pfik_ifp,
+ r->rule_flag & PFRULE_RETURNICMPASDEST);
else if ((af == AF_INET6) && r->return_icmp6)
pf_send_icmp(m, r->return_icmp6 >> 8,
- r->return_icmp6 & 255, af, r);
+ r->return_icmp6 & 255, af, r, pd->eh, kif->pfik_ifp,
+ r->rule_flag & PFRULE_RETURNICMPASDEST);
}
if (r->action != PF_PASS)
Index: sys/net/pfvar.h
===
RCS file: /cvs/src/sys/net/pfvar.h,v
retrieving revision 1.197
diff -u -r1.197 pfvar.h
--- sys/net/pfvar.h 14 Jun 2004 20:53:27 - 1.197
+++ sys/net/pfvar.h 21 Jun 2004 15:18:41 -
@@ -540,6 +540,7 @@
#definePFRULE_NOSYNC 0x0010
#define PFRULE_SRCTRACK0x0020 /* track source states */
#define PFRULE_RULESRCTRACK0x0040 /* per rule */
+#define PFRULE_RETURNICMPASDEST0x0080
/* scrub flags */
#definePFRULE_NODF 0x0100
Index: sys/netinet/ip_icmp.c
===
RCS file: /cvs/src/sys/netinet/ip_icmp.c,v
retrieving revision 1.64
diff -u -r1.64 ip_icmp.c
--- sys/netinet/ip_icmp.c 6 Jun 2004 16:49:09 - 1.64
+++ sys/netinet/ip_icmp.c 21 Jun 2004 15:18:42 -
@@ -615,7 +615,6 @@
struct in_ifaddr *ia;
struct in_addr t;
struct mbuf *opts = 0;
- int optlen = (ip->ip_hl << 2) - sizeof(struct ip);
if (!in_canforward(ip->ip_src) &&
((ip->ip_src.s_addr & IN_CLASSA_NET) !=
@@ -672,6 +671,21 @@
ip->ip_src = t;
ip->ip_ttl = MAXTTL;
+ opts = icmp_reflect_options(m);
+ m->m_flags &= ~(M_BCAST|M_MCAST);
+ icmp_send(m, opts);
+done:
+ if (opts)
+ (void)m_free(opts);
+}
+
+struct mbuf *
+icmp_reflect_options(struct mbuf *m)
+{
+ struct ip *ip = mtod(m, struct ip *);
+ int optlen = (ip->ip_hl << 2) - sizeof(struct ip);
+ struct mbuf *opts = 0;
+
if (optlen > 0) {
u_char *cp;
int opt, cnt;
@@ -744,11 +758,7 @@
bcopy((caddr_t)ip + optlen, (caddr_t)(ip + 1),
(unsigned)(m->m_len - sizeof(struct ip)));
}
- m->m_flags &= ~(M_BCAST|M_MCAST);
- icmp_send(m, opts);
-done:
- if (opts)
- (void)m_free(opts);
+ return (opts);
}
/*
Index: sys/netinet/ip_icmp.h
===
RCS file: /cvs/src/sys/netinet/ip_icmp.h,v
retrieving revision 1.20
diff -u -r1.20 ip_icmp.h
--- sys/netinet/ip_icmp.h 2 Jun 2003 23:28:14 - 1.20
+++ sys/netinet/ip_icmp.h 21 Jun 2004 15:18:42 -
@@ -211,6 +211,8 @@
void icmp_input(struct mbuf *, ...);
void icmp_init(void);
void icmp_reflect(struct mbuf *);
+struct mbuf *
+ icmp_reflect_options(struct mbuf *);
void icmp_send(struct mbuf *, struct mbuf *);
inticmp_sysctl(int *, u_int, void *, size_t *, void *, size_t);
struct rtentry *
Index: share/man/man5/pf.conf.5
===
RCS file: /cvs/src/share/man/man5/pf.conf.5,v
retrieving revision 1.297
diff -u -r1.297 pf.conf.5
--- share/man/man5/pf.conf.59 May 2004 10:51:55 - 1.297
+++ share/man/man5/pf.conf.521 Jun 2004 15:18:45 -
@@ -1110,6 +1110,13 @@
This causes ICMP messages to be returned for packets which match the rule.
By default this is an ICMP UNREACHABLE message, however this
can be overridden by specifying a message as a code or number.
+.It Ar return-icmp-as-dest
+This does the same as
+.Ar return-icmp ,
+but makes the ICMP packet appear to come from the destination host.
+Unlike
+.Ar return-icmp ,
+this will work on pure bridge.
.It Ar return
This causes a TCP RST to be returned for
.Xr tcp 4
@@ -2524,6 +2531,8 @@
return = "drop" | "return" | "return-rst" [ "( ttl" number ")" ] |
"return-icmp" [ "(" icmpcode ["," icmp6code ] ")" ] |
"return-icmp6" [ "(" icmp6code ")" ]
+"return-icmp-as-dest" [ "(" icmpcode ")" ] |
+
icmpcode = ( icmp-code-name | icmp-code-number )
icmp6code = ( icmp6-code-name | icmp6-code-number )
Index: sbin/pfctl/parse.y
===
RCS file: /cvs/src/sbin/pfctl/parse.y,v
retrieving revision 1.455
diff -u -r1.455 parse.y
--- sbin/pfctl/parse.y 10 Jun 2004 14:22:54 - 1.455
+++ sbin/pfctl/parse.y 21 Jun 2004 15:18:49 -
Re: bridge tagging limits?
On Thu, May 27, 2004 at 04:56:41PM -0400, Jim Zajkowski wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all, > > Does anyone have any experience with the number of rules a bridge can > handle? We're thinking about how our wireless network policy, and we'd > like to filter by MAC -- allow connection we know about (with pf) and > redirect everyone else into a "please call this number" web page. I'm > concerned about pushing 500 or more rules onto a bridge just to tag > which MACs we know about versus which we don't. bridge rules are stored on a linked list and evaluated for every packet thus having many rules will definitely affect performance. Although you should be able to evaluate the performance easily within your environment. > University environments can be so interesting. :-) :)
bridge tagging limits?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Does anyone have any experience with the number of rules a bridge can handle? We're thinking about how our wireless network policy, and we'd like to filter by MAC -- allow connection we know about (with pf) and redirect everyone else into a "please call this number" web page. I'm concerned about pushing 500 or more rules onto a bridge just to tag which MACs we know about versus which we don't. University environments can be so interesting. :-) Thanks, - --Jim (I do realize this is openbsd-pf, but openbsd-bridge doesn't exist, and this group is most likely to know) - - - - Jim Zajkowski OpenPGP 0x21135C3http://www.jimz.net/pgp.asc System Administrator 8A9E 1DDF 944D 83C3 AEAB 8F74 8697 A823 2113 5C53 UM Life Sciences Institute -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) iD8DBQFAtlYJhpeoIyETXFMRAvgYAKDSpDvNfXmXGB3qKGNJZjLdS157mQCgrQ7o OyC3TpYrZc6TzcLD+kqSc7c= =HksB -END PGP SIGNATURE-
Re: 3-way transparent bridge?
On Sat, 15 May 2004 21:05:36 +0300 Toni wrote: > Is it possible to use 3-way transparent bridge (with two ISP's)? > > There were no errors while creating this, but I haven't connected it > yet... If it works, is there anything special I need to think of with > PF rules? > > > --[isp1]--\ > [fw]--[switch]--(dmz, public addresses from both isp's) > --[isp2]--/ Wouldn't "Load Balance Outgoing Traffic" as described in http://www.openbsd.org/faq/pf/pools.html solve your problem? "Address pools can be used in combination with the route-to filter option to load balance two or more Internet connections when a proper multi-path routing protocol (like BGP4) is unavailable. By using route-to with a round-robin address pool, outbound connections can be evenly distributed among multiple outbound paths." /fredrik
bridge between two cisco's..
Hello all, I had made a bridge in 3.4 w/ altq and it seemed to do everything that I was looking for. The box was taken out for updating and upgrading (from 3.4 to 3.5 patch6) when it came back all traffic was dumped into the default queues. Also during the time that the box was out vlans were put in place. About 10-15 of them. the layout is as follows: inet -> fe0 [3620] fe1 -> fxp0 [obsd 3.5] fxp1 -> 1/e1 [dell3348] -> other when I tcpdump my fxp0 and fxp1 inet faces I could see the vlan encapsulated packets.. If anyone would like to see my config file I can post it, but I guess I'm wondering if someone has a simmilar setup (router w/vlans -> obsd bridge -> network) and how they got altq to work (if at all). Thanks for taking the time to read this. - Brian
Re: squid+pf+transparent bridge
On Mon, May 17, 2004 at 03:19:25PM -0700, Bryan Irvine wrote: > do you have a "pass" line as well? > > Follow these directions closely. > > www.benzedrine.cx/transquid.html > > --Bryan In addition to this, since you are using a bridgeyou will have to route the redirected packets to the loopback interface in the related pass rule. Search the archives for details.
Re: squid+pf+transparent bridge
On Mon, May 17, 2004 at 03:58:05PM -0600, [EMAIL PROTECTED] wrote: > Hello, > > I set up a transparent firewall running 3.4. Now Ive been > asked to run squid on the same box as the firewall to increase > web traffic (hopefully). Ive installed another NIC with > an IP and set up squid to listen on that card. I tested squid > by manually configuring a web browser to use the firewall's > IP'ed NIC as the proxy. > > In the pf.conf I have a redirect line: > rdr on $int_if inet proto tcp from ! $loc_if to any port www -> > $loc_if port 3128 > > Any help would greatly help! what's not working? please don't tell me you don't have that stuff in squid.conf that i've posted up about a three/four times before and also which afaik, daniel has on his www? jared -- [ openbsd 3.5 GENERIC ( may 10 ) // i386 ]
Re: squid+pf+transparent bridge
do you have a "pass" line as well? Follow these directions closely. www.benzedrine.cx/transquid.html --Bryan On Mon, 2004-05-17 at 14:58, [EMAIL PROTECTED] wrote: > Hello, > > I set up a transparent firewall running 3.4. Now Ive been > asked to run squid on the same box as the firewall to increase > web traffic (hopefully). Ive installed another NIC with > an IP and set up squid to listen on that card. I tested squid > by manually configuring a web browser to use the firewall's > IP'ed NIC as the proxy. > > In the pf.conf I have a redirect line: > rdr on $int_if inet proto tcp from ! $loc_if to any port www -> > $loc_if port 3128 > > Any help would greatly help! > > Thanks! > > David >
squid+pf+transparent bridge
Hello, I set up a transparent firewall running 3.4. Now Ive been asked to run squid on the same box as the firewall to increase web traffic (hopefully). Ive installed another NIC with an IP and set up squid to listen on that card. I tested squid by manually configuring a web browser to use the firewall's IP'ed NIC as the proxy. In the pf.conf I have a redirect line: rdr on $int_if inet proto tcp from ! $loc_if to any port www -> $loc_if port 3128 Any help would greatly help! Thanks! David
Re: 3-way transparent bridge?
On 16 May 2004 15:44:38 -0700, [EMAIL PROTECTED] (Toni Riekkinen) wrote: >Greg Hennessy wrote: > > >But this leaves the problem, webservers defaultroute points to ISP1 and >the replies would go there anyways? It wont work any other way, asymmetric routes are not pleasant to deal with at the best of times. > Is the only solution to define ip in >my fw for routing and forget transparency? Layer 3 is the way to go. greg -- "vying with Platt for the largest gap between capability and self perception"
Re: 3-way transparent bridge?
Greg Hennessy wrote: How are you going to decide on what default route to use to get packets out there ? I was kind of hoping for someone to point that out. :) The purpose is to protect same webservers in same DMZ, if possible. So the traffic is outgoing. Then, I could handle by dns through which ISP pipe traffic goes. I guess what I had in mind was if could use route-to/reply-to in transparent bridge? Something like: ### default ISP pass in quick on $isp1_if proto tcp \ from any to $webserver_ip1 port 80 \ flags S/SA modulate state ### alternate ISP pass in quick on $isp2_if reply-to $isp2_if proto tcp \ from any to $webserver_ip2 port 80 \ flags S/SA modulate state But this leaves the problem, webservers defaultroute points to ISP1 and the replies would go there anyways? Is the only solution to define ip in my fw for routing and forget transparency? -- Regards, Toni
Re: 3-way transparent bridge?
On 15 May 2004 18:12:41 -0700, [EMAIL PROTECTED] (Toni Riekkinen) wrote: >Hi, > >Is it possible to use 3-way transparent bridge (with two ISP's)? > How are you going to decide on what default route to use to get packets out there ? greg -- "vying with Platt for the largest gap between capability and self perception"
3-way transparent bridge?
Hi, Is it possible to use 3-way transparent bridge (with two ISP's)? There were no errors while creating this, but I haven't connected it yet... If it works, is there anything special I need to think of with PF rules? --[isp1]--\ [fw]--[switch]--(dmz, public addresses from both isp's) --[isp2]--/ /etc/hostname.if[0-2] up media 100baseTX mediaopt full-duplex /etc/bridgename.bridge0 add if0 add if1 add if2 blocknonip if0 blocknonip if1 blocknonip if2 up -- Regards, Toni
Re: transparrant pf bridge
On Wed, May 05, 2004 at 05:29:57PM +0100, P.Harmsen wrote: > The following pf.conf works but i > wonder if it makes sence /has any effect. What you quoted contains syntax errors and won't parse, so how do you come to the conclusion that it "works"? If those are just typos, repost the precise ruleset. Precision is important in this case, people won't guess what is a typo in a mail and what might be a typo in pf.conf. First, fix the syntax errors (pfctl tells you what lines they're on, for instance & vs. $ on macros, trailing :, etc.). Then verify pfctl successfully loads the ruleset and compare pfctl -sr output (that's the ruleset that is being used). Make sure pf is enabled (pfctl -e). Now test connections that should work and connections that should be blocked. This is your tasks as the admin. We don't write your ruleset for you, rather, we may help you resolve questions or problems writing it. The point being that you do the bulk of the work, and ask specific questions :) Daniel
transparrant pf bridge
hello i have installed a transparant bridge between two routers
infront_rl0 and behind_ rl1
the below is my pf.conf ( first time i ever wrote it )
I wonder if this firewall (OpenBSD3.5) conf i wrote makes any sence
.Both routers allso function as dhcp servers.
clients of behind_rl1 only need to access ftp,msn mesenger service pop3
mail and should be able to
get their ip-address automatically.The following pf.conf works but i
wonder if it makes sence /has any effect.
ext_if = "rl0"
int_if = "rl1"
tcp_services = "{bootpc,bootps,domain}"
udp_services = "{bootpc, bootps,domain}"
set block-policy return
set loginterface &ext_if
scrub in on $ext_if all
scrub in on $int_it all
block in on &ext_if all
pass quick on lo0 all:
pass out on $ext_if proto tcp from any to ($ext_if) \
port $tcp_services flags S/SA modulate state
pass out on $ext_if proto udp from any to ($ext_if) \
port $udp_services flags S/SA keep state
pass in on $ext_if proto udp from any to any
pass out on $int_if proto tcp all modulate state flags S/SA
pass out on $int_if proto {udp,icmp} all keep state
cheers
Re: Traffic shaping in two directions on bridge
Bruno Afonso wrote: Per-Olov Sjöholm wrote: Bruno Afonso said: Henning Brauer wrote: This means that over 90% of all bridge examples I have seen on the net where queueing takes place in two directions are wrong. that may be the case. You can simply queue on the outgoing of the INTERNAL interface to limit download bandwidth. That's why normally people queue on both interfaces. ? Why queue on both interfaces if you want to limit only the download? Maybe tag the packets on the Internet interface but use altq on the lan interface... Isn't that one of the basics to queue on the interface where the packet leaves the firewall? Did you mix up tagging and the queuing itself? Or did I miss something here? Then somebody can be nice to correct me... How can you limit the download if you can only limit on the outgoing of an interface? You CANNOT limit what the ISP sends you. So, you can only limit what you send to the internal network on the internal interface outgoing traffic. You can use tagging or whatever techniques you fancy but you will need to have to use altq on the lan interface. This is what I said. Tagging is extremely useful for NAT setups for example. I am not doing anything against the basics here. I am using altq when the packet leaves the firewall, when it leaves the internal interface of the firewall. Why do you assume when it leaves the firewall it must leave into the internet? Well, you could always time the ACKs that you send. So if you assign X bps on the outside interface to IP0, and you get a lot of packets, they will chocke the bandwidth allocation and your ACKs will be delayed, so the other side will back off until it gets comfortable with the ACKs rate. So you can actually allocate bandwidth on hte OUTSIDE interface.
Re: Traffic shaping in two directions on bridge
Alejandro G. Belluscio wrote: Well, you could always time the ACKs that you send. So if you assign X bps on the outside interface to IP0, and you get a lot of packets, they will chocke the bandwidth allocation and your ACKs will be delayed, so the other side will back off until it gets comfortable with the ACKs rate. So you can actually allocate bandwidth on hte OUTSIDE interface. Well, in theory maybe but I don't believe it will work ok. You want to limit 100kb/s download, what bw will you set the acks pipe to? :-) If you really have made this work as you expect to, it's an interesting way to approach it, but I don't see any benefit in it. Is there? ps: maybe we should start another thread? BA -- Bruno Miguel Afonso Biological Eng. student D.E.Q. @ I.S.T. - Portugal GnuPG Public key: http://dequim.ist.utl.pt/~bruno/gpg
Re: Traffic shaping in two directions on bridge
Per-Olov Sjöholm wrote: From my point of view it only seems like this discussion leads to missunderstanding. And as this is no longer a "queueing on a bridge" discussion, I think we end this thread here... However, if somebody think I am terrible wrong I of course want to be corrected. Per-Olov, I am not going to argue against what you said. Apparently I missunderstood what you said. But, I still continue to say queue on both interfaces. While you want to limit the download I also normally prioritize acks or uploads on the internet side. That is why I use on both interfaces but they don't have the same effect of course. I hope this is clear now. ps: this is way way OT. :-) Take care, bruno -- Bruno Miguel Afonso Biological Eng. student D.E.Q. @ I.S.T. - Portugal GnuPG Public key: http://dequim.ist.utl.pt/~bruno/gpg
Re: Traffic shaping in two directions on bridge
Bruno Afonso said: > Per-Olov Sjöholm wrote: > >> Bruno Afonso said: >> >>>Henning Brauer wrote: >>> >>> >>> >>>>>This means that over 90% of all >>>>>bridge examples I have seen on the net where queueing takes place in >>>>> two >>>>>directions are wrong. >>>> >>>>that may be the case. >>> >>>You can simply queue on the outgoing of the INTERNAL interface to limit >>>download bandwidth. That's why normally people queue on both interfaces. >>> >> >> >> ? >> Why queue on both interfaces if you want to limit only the download? >> Maybe >> tag the packets on the Internet interface but use altq on the lan >> interface... >> Isn't that one of the basics to queue on the interface where the packet >> leaves the firewall? Did you mix up tagging and the queuing itself? Or >> did >> I miss something here? Then somebody can be nice to correct me... > > How can you limit the download if you can only limit on the outgoing of > an interface? You CANNOT limit what the ISP sends you. So, you can only > limit what you send to the internal network on the internal interface > outgoing traffic. Isn't that what I said? Queue on the inteface where the packet leaves the firewall. A download from the internet to your PC on the lan gives queueing on the lan interface of the firewall. During a download from the internet the packet come in on the Internet interface and goes out (leaves) on the lan interface. Which of course means that the queueing will be done on the lan interface. > > You can use tagging or whatever techniques you fancy but you will need > to have to use altq on the lan interface. This is what I said. Tagging > is extremely useful for NAT setups for example. You said: -- "You can simply queue on the outgoing of the INTERNAL interface to limit download bandwidth. That's why normally people queue on both interfaces." -- You mention queue on "both" interfaces which means altq on two intefaces and not just the lan interface. > > I am not doing anything against the basics here. I am using altq when > the packet leaves the firewall, when it leaves the internal interface of > the firewall. Why do you assume when it leaves the firewall it must > leave into the internet? I definetly don't assume that! Did not said that! Can "the interface where the packet leves the firewall" be missunderstood ? If the packet goes out on the lan it leaves the LAN inteface. If the packet goes to the internet it leaves the INTERNET inteface. So queuing of download from the internet takes place on the LAN interface. > > > -- > Bruno Miguel Afonso > Biological Eng. student > D.E.Q. @ I.S.T. - Portugal > GnuPG Public key: http://dequim.ist.utl.pt/~bruno/gpg > >From my point of view it only seems like this discussion leads to missunderstanding. And as this is no longer a "queueing on a bridge" discussion, I think we end this thread here... However, if somebody think I am terrible wrong I of course want to be corrected. Thanks Per-Olov Sjöholm
Re: Traffic shaping in two directions on bridge
Bruno Afonso said: > Henning Brauer wrote: > > >>>This means that over 90% of all >>>bridge examples I have seen on the net where queueing takes place in two >>>directions are wrong. >> >> that may be the case. > > You can simply queue on the outgoing of the INTERNAL interface to limit > download bandwidth. That's why normally people queue on both interfaces. > ? Why queue on both interfaces if you want to limit only the download? Maybe tag the packets on the Internet interface but use altq on the lan interface... Isn't that one of the basics to queue on the interface where the packet leaves the firewall? Did you mix up tagging and the queuing itself? Or did I miss something here? Then somebody can be nice to correct me... > Best, > BA > -- > Bruno Miguel Afonso > Biological Eng. student > D.E.Q. @ I.S.T. - Portugal > GnuPG Public key: http://dequim.ist.utl.pt/~bruno/gpg > What you write can be found in the PF FAQ and the man pages which of course is the place where everyone should start to look before posting. But it seems like many people think they can enable altq on just one interface because it's a bridge, even though they filter both incoming and outgoing traffic. And good bridge examples with queueing is not easy to find. Well... not correct ones. The reason for the posting the first time was that the FAQ said it was highly recommended to do the main filtering for a bridge on just one interface. And then I first thought (as I couldn't find much bridge info) that it could also affect the queuing in some strange way. But that is obviously not the case. Thanks /Per-Olov Sjöholm
Re: Traffic shaping in two directions on bridge
Per-Olov Sjöholm wrote: Bruno Afonso said: Henning Brauer wrote: This means that over 90% of all bridge examples I have seen on the net where queueing takes place in two directions are wrong. that may be the case. You can simply queue on the outgoing of the INTERNAL interface to limit download bandwidth. That's why normally people queue on both interfaces. ? Why queue on both interfaces if you want to limit only the download? Maybe tag the packets on the Internet interface but use altq on the lan interface... Isn't that one of the basics to queue on the interface where the packet leaves the firewall? Did you mix up tagging and the queuing itself? Or did I miss something here? Then somebody can be nice to correct me... How can you limit the download if you can only limit on the outgoing of an interface? You CANNOT limit what the ISP sends you. So, you can only limit what you send to the internal network on the internal interface outgoing traffic. You can use tagging or whatever techniques you fancy but you will need to have to use altq on the lan interface. This is what I said. Tagging is extremely useful for NAT setups for example. I am not doing anything against the basics here. I am using altq when the packet leaves the firewall, when it leaves the internal interface of the firewall. Why do you assume when it leaves the firewall it must leave into the internet? -- Bruno Miguel Afonso Biological Eng. student D.E.Q. @ I.S.T. - Portugal GnuPG Public key: http://dequim.ist.utl.pt/~bruno/gpg
