News: This forum is now permanently frozen.
Pages: [1]
Topic: Packet loss in bridge mode, not on LAN  (Read 3378 times)
« on: March 25, 2010, 15:12:40 »
bluefox *
Posts: 6

Hi,

I'm new here, so hi! :-)

I've finally successfuly setup Monowall (latest and greatest release version as of today) pretty much as described here, with one WAN, one LAN and one bridged NIC (and 3 unused NIC):
http://doc.m0n0.ch/handbook/examples-filtered-bridge.html

Firewall, for testing purposes, is 100% open. I've got two laptops plugged in, one on the LAN and one on the bridge.  IP addresses given to both laptops are consistent with what I would expect from each.

I've noticed something unexpected though: I've setup a ping (to the same address, a server hosted at a data center that I own) on both.  The LAN computer is getting great ping, but the bridged computer is getting packet loss (about 5%).  The link is underused on both sides, and nothing much is happening on the computers either.

Should I be getting so much packet loss simply because it's a bridged interface? Is this a known bug/feature? I tried switching the NIC card used for bridging since I had extra ones available same problem on any card.

Thanks,

Mike
« Reply #1 on: March 25, 2010, 17:11:45 »
bluefox *
Posts: 6

Quick follow-up on the matter. I see in my logs that on the WAN interface some echoreply packet were discarded.   So it makes sense to have packet loss, BUT...

My WAN rules are "allow all", and I even have an extra rule allowing all ICMP packets in to make sure.  There are still some being blocked incoming.

In what circumstances would the firewall block something against my wishes?
« Reply #2 on: March 25, 2010, 17:28:22 »
bluefox *
Posts: 6

And yet another piece of info:

Thisis my log entry:
16:30:07.434062 rl0 @0:9 b 69.70.204.138 -> 192.168.1.100 PR icmp len 20 60 icmp echoreply/0 OUT

This seems to be the rule blocking my packets:

@9 block in log quick on xl1 from !192.168.0.0/24 to any

I never put such a rule in, so where do I remove it?
« Last Edit: March 25, 2010, 17:30:47 by bluefox »
« Reply #3 on: March 25, 2010, 17:56:29 »
brushedmoss ****
Posts: 446

It's part of the built in rules.

If this is 1.31 and it's a bridge, there is an option in advanced settings to disable spoof checking on bridges, should fix this for you if the source and destination are on bridged interfaces
« Reply #4 on: March 25, 2010, 17:59:56 »
bluefox *
Posts: 6

Yeah I figured this would work, but it didn't. Rule is still there, and it is a bridged interface.

Or course disabling ipfilters completely work, but that's not the point of a firewall :-)
« Reply #5 on: March 25, 2010, 19:46:34 »
brushedmoss ****
Posts: 446

69.x.x.x came in on rl0 destined to 192.168.1.100

the rule you indicate is a problem is for 192.168.0.0/24 on interface xl1 which is a different network to 192.168.1.100 ??
« Reply #6 on: March 25, 2010, 19:54:42 »
bluefox *
Posts: 6

No firewall expert here, I thought from my programming experience that !192.168.0.0/24 was anything NOT 192.168.0.0/24.

Here is my complete ipf table
@1 pass out quick on lo0 all
@2 pass out quick on xl1 proto udp from 192.168.0.1/32 port = bootps to any port = bootpc
@3 pass out quick on vr0 proto udp from any port = bootpc to any port = bootps
@4 pass out quick on xl1 all keep state
@5 pass out quick on vr0 all keep state
@6 pass out quick on rl0 all keep state
@7 pass out quick on rl1 all keep state
@8 pass out quick on xl0 all keep state
@9 block out log quick all
@1 pass in quick on lo0 all
@2 block in log quick from any to any with short
@3 block in log quick from any to any with ipopts
@4 pass in quick on xl1 proto udp from any port = bootpc to 255.255.255.255/32 port = bootps
@5 pass in quick on xl1 proto udp from any port = bootpc to 192.168.0.1/32 port = bootps
@6 block in log quick on vr0 from 192.168.0.0/24 to any
@7 block in log quick on vr0 proto udp from any port = bootps to 192.168.0.0/24 port = bootpc
@8 pass in quick on vr0 proto udp from any port = bootps to any port = bootpc
@9 block in log quick on xl1 from !192.168.0.0/24 to any
@10 skip 1 in proto tcp from any to any flags S/FSRA
@11 block in log quick proto tcp from any to any
@12 block in log quick on xl1 all head 100
@13 block in log quick on vr0 all head 200
@14 block in log quick on rl0 all head 300
@15 block in log quick on rl1 all head 400
@16 block in log quick on xl0 all head 500
@17 block in log quick all
# Group 100
@1 pass in quick from 192.168.0.0/24 to 192.168.0.1/32 keep state group 100
@2 pass in quick from 192.168.0.0/24 to any keep state group 100
# Group 200
@1 pass in log first quick proto icmp from any to any keep state keep frags group 200
@2 pass in quick from any to any keep state keep frags group 200
# Group 300
@1 pass in quick proto icmp from any to any keep state keep frags group 300
@2 pass in quick from any to any keep state keep frags group 300
# Group 400
@1 pass in quick from any to any keep state group 400
# Group 500
@1 pass in quick from any to any keep state group 500

unparsed ipnat rules

map vr0 192.168.0.0/24  -> 0/32 proxy port 21 ftp/tcp
map vr0 192.168.0.0/24  -> 0/32 portmap tcp/udp 1024:64535
map vr0 192.168.0.0/24  -> 0/32
map vr0 from 192.168.1.8/32 to any port = 53 -> 0.0.0.0/32 tcp/udp

unparsed ipfilter rules

# loopback
pass in quick on lo0 all
pass out quick on lo0 all
# block short packets
block in log quick all with short

# block IP options
block in log quick all with ipopts

# allow access to DHCP server on LAN
pass in quick on xl1 proto udp from any port = 68 to 255.255.255.255 port = 67
pass in quick on xl1 proto udp from any port = 68 to 192.168.0.1 port = 67
pass out quick on xl1 proto udp from 192.168.0.1 port = 67 to any port = 68

# WAN spoof check
block in log quick on vr0 from 192.168.0.0/24 to any

# allow our DHCP client out to the WAN
# XXX - should be more restrictive
# (not possible at the moment - need 'me' like in ipfw)
pass out quick on vr0 proto udp from any port = 68 to any port = 67
block in log quick on vr0 proto udp from any port = 67 to 192.168.0.0/24 port = 68
pass in quick on vr0 proto udp from any port = 67 to any port = 68

# LAN/OPT spoof check (needs to be after DHCP because of broadcast addresses)
block in log quick on xl1 from ! 192.168.0.0/24 to any

# Block TCP packets that do not mark the start of a connection
skip 1 in proto tcp all flags S/SAFR
block in log quick proto tcp all

#---------------------------------------------------------------------------
# group head 100 - LAN interface
#---------------------------------------------------------------------------
block in log quick on xl1 all head 100

# let out anything from the firewall host itself and decrypted IPsec traffic
pass out quick on xl1 all keep state

#---------------------------------------------------------------------------
# group head 200 - WAN interface
#---------------------------------------------------------------------------
block in log quick on vr0 all head 200

# let out anything from the firewall host itself and decrypted IPsec traffic
pass out quick on vr0 all keep state
      
#---------------------------------------------------------------------------
# group head 300 - opt1 interface
#---------------------------------------------------------------------------
block in log quick on rl0 all head 300

# let out anything from the firewall host itself and decrypted IPsec traffic
pass out quick on rl0 all keep state
      
#---------------------------------------------------------------------------
# group head 400 - opt2 interface
#---------------------------------------------------------------------------
block in log quick on rl1 all head 400

# let out anything from the firewall host itself and decrypted IPsec traffic
pass out quick on rl1 all keep state
      
#---------------------------------------------------------------------------
# group head 500 - opt3 interface
#---------------------------------------------------------------------------
block in log quick on xl0 all head 500

# let out anything from the firewall host itself and decrypted IPsec traffic
pass out quick on xl0 all keep state

# make sure the user cannot lock himself out of the webGUI
pass in quick from 192.168.0.0/24 to 192.168.0.1 keep state group 100

# User-defined rules follow
pass in log first quick proto icmp from any to any keep state keep frags group 200
pass in quick from any to any keep state keep frags group 200
pass in quick from any to any keep state group 500
pass in quick from any to any keep state group 400
pass in quick proto icmp from any to any keep state keep frags group 300
pass in quick from any to any keep state keep frags group 300
pass in quick from 192.168.0.0/24 to any keep state group 100
   
#---------------------------------------------------------------------------
# default rules (just to be sure)
#---------------------------------------------------------------------------
block in log quick all
block out log quick all
« Reply #7 on: March 25, 2010, 21:14:44 »
brushedmoss ****
Posts: 446

yes !192.168.0.0/24 is a NOT statement, but this is created because the subnet of xl1 is 192.168.0.0/24, so why would you expect a packet destined to 192.168.1.0/24 , to be allowed to be sent there ?

I don't see anything in your firewall rules to indicate where 192.168.1.0/24 is configured or exists ?
« Reply #8 on: March 25, 2010, 21:25:50 »
bluefox *
Posts: 6

I have both a "bridged to WAN" NIC and a LAN NIC.  192.168.0.1 is my LAN address, while the Bridged NIC card should pick up 192.168.1.x addresses.  The setup may not make any production sense, because its in testing here until I am comfortable putting this in prod.

Tomato Router
|
Monowall WAN 192.168.1.8 ---- LAN (192.168.0.1)
|-----------OPT1 (bridged to WAN)

The OPT1 connected devices should therefore act as if they were connected to the Tomato-based router. (if I understand correctly) but with possible filtering.

So I have a ping going from one bridged PC (192.168.1.100, address given by the Tomato router since its bridged to it hrough Monowall) to some external address, and ping echos should come back to it (192.168.1.100).  But they are being blocked by that rule. But only some times, because I only get a 5% packet loss. The other 95% are going through perfectly.

Why is this inconsistent?



 
Pages: [1]
 
 
Powered by SMF 1.1.20 | SMF © 2013, Simple Machines