DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD General

OpenBSD General Other questions regarding OpenBSD which do not fit in any of the categories below.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 6th February 2013
KBr KBr is offline
New User
 
Join Date: May 2012
Posts: 5
Thanked 0 Times in 0 Posts
Default connection breakdown by route-to rule

Hi,

besides other useful things I have following statements in my pf.conf:

table <INT> { 172.16.0.0/16, 192.168.0.0/24, 192.168.1.0/24 }
pass in on vlan7 inet from {vlan7:network} to !<INT> route-to (vlan7 192.168.1.254)

The rational behind it is that I had to integrate a formerly autonomous department into my LAN. The department insists on keeping their own DSL-router for all outbound traffic from that subnet for access to the internet, not the router the rest of the LAN uses, as the bandwidth of that router is infamously limited.
The statements do work so far. Only: There are regular connection breakdowns during larger downloads and display of streaming content is rather jerky.

The other subnets routed through the machine the filter is running on are not having issues of this kind. So I do not think, the hardware (Pentium4 Box with GBit-Interfaces) is inappropriate for the task. Connection breakdowns only occur when the traffic is routed through that common router and redirected to the department-router. There aren't any problems when traffic is routed directly through the department-router. So I suspect my 'route-to' rule being to blame.

Can anybody help me here? Any hints on what to look for are appreciated.
Reply With Quote
  #2   (View Single Post)  
Old 6th February 2013
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 3,116
Thanked 182 Times in 149 Posts
Default

You could check whether TCP window scaling is working.

Code:
# pfctl -vvss | grep -C1 wscale
all tcp 129.128.5.191:54009 (129.128.5.191:63506) <- 192.168.222.20:38781       FIN_WAIT_2:FIN_WAIT_2
   [2816903347 + 102808] wscale 3  [1483341881 + 17376] wscale 3
   age 00:00:54, expires in 00:00:41, 239:386 pkts, 12440:575325 bytes, rule 29
See
Create TCP states on the initial SYN packet
for an explanation.

Which version of OpenBSD are you using?
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
  #3   (View Single Post)  
Old 6th February 2013
KBr KBr is offline
New User
 
Join Date: May 2012
Posts: 5
Thanked 0 Times in 0 Posts
Default

As it seems, window scaling is active:

root:2# sysctl net.inet.tcp.rfc1323
net.inet.tcp.rfc1323=1

and I see the wscale term in the output of the pfctl command.
It's OpenBSD 5.0. I hope it's ok so far, I am not keen on updating this box. Thank you for the link. Much to read. May be I get another hint there.

Quote:
Originally Posted by J65nko View Post
You could check whether en.wikipedia.org/wiki/TCP_window_scale_option]TCP window scaling is working.

Code:
# pfctl -vvss | grep -C1 wscale
all tcp 129.128.5.191:54009 (129.128.5.191:63506) <- 192.168.222.20:38781       FIN_WAIT_2:FIN_WAIT_2
   [2816903347 + 102808] wscale 3  [1483341881 + 17376] wscale 3
   age 00:00:54, expires in 00:00:41, 239:386 pkts, 12440:575325 bytes, rule 29
See undeadly.org/cgi?action=article&sid=20060928081238
Create TCP states on the initial SYN packet for an explanation.

Which version of OpenBSD are you using?
Reply With Quote
  #4   (View Single Post)  
Old 6th February 2013
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,429
Thanked 214 Times in 189 Posts
Default

Hello, and welcome!
Quote:
Originally Posted by KBr View Post
...There are regular connection breakdowns during larger downloads and display of streaming content is rather jerky....Any hints on what to look for are appreciated.
I'm wondering if a scarcity of mbufs or mbuf clusters might be possible cause. Using the -m option of netstat(1) while those packets are in transit may provide an indication of an mbuf problem or rule this out as a possiblity. Of course if the kernel exhausts mbufs completely, it will panic.

Support for OpenBSD 5.0 ceased on 1 Nov 2012 when OpenBSD 5.2 was released. Since 5.0, there have been network stack improvements including, at 5.1, "Improved vlan priority support, including mapping to interface queues" and at 5.2, "Increased TCP initial window to 14600 bytes as proposed in draft-ietf-tcpm-initcwnd." While you do not desire an upgrade it is possible that your problem has been resolved by developments implemented since 18 July 2011, when new development ceased for what became 5.0-release.

Even though 5.0 is no longer supported, you might consider posting about the problem on the misc@ mailing list; it is a larger audience and it is possible you will get better advice from more knowledgeable people, including developers. If you have not posted to OpenBSD project mailing lists before, please see http://www.openbsd.org/mail.html for guidance.

Last edited by jggimi; 6th February 2013 at 01:25 PM. Reason: typos
Reply With Quote
  #5   (View Single Post)  
Old 6th February 2013
KBr KBr is offline
New User
 
Join Date: May 2012
Posts: 5
Thanked 0 Times in 0 Posts
Default

To my understanding the filter on my default router (192.168.1.5) redirects outbound packets from the subnet 192.168.1.0 - say the host 192.168.1.10 - to the router 192.168.1.254 without touching them. It's just creating a new frame with the destination MAC-Address of 192.168.1.254 and his own MAC as source address. The new router removes the frame, then rewrites the source IP of the packets while registering the original local source address and sends it to the router of our provider. All incoming answering traffic for that host 192.168.1.10 is sent by the router 192.168.1.254 (after rewriting the destination address) directly to the local destination host 192.168.1.10 without involvement of the initial default router 192.168.1.5. So only outbound packets run through my default gateway, all incoming traffic is delivered directly. A netstat -m on my OpenBSD-router during large downloads would not provide any useful information. Or am I missing something here?
Is there a way to upgrade the router directly from 5.0 to 5.2?

Quote:
Originally Posted by jggimi View Post
Hello, and welcome!I'm wondering if a scarcity of mbufs or mbuf clusters might be possible cause. Using the -m option of netstat(1) while those packets are in transit may provide an indication of an mbuf problem or rule this out as a possiblity. Of course if the kernel exhausts mbufs completely, it will panic.

Support for OpenBSD 5.0 ceased on 1 Nov 2012 when OpenBSD 5.2 was released. Since 5.0, there have been network stack improvements including, at 5.1, "Improved vlan priority support, including mapping to interface queues" and at 5.2, "Increased TCP initial window to 14600 bytes as proposed in draft-ietf-tcpm-initcwnd." While you do not desire an upgrade it is possible that your problem has been resolved by developments implemented since 18 July 2011, when new development ceased for what became 5.0-release.

Even though 5.0 is no longer supported, you might consider posting about the problem on the misc@ mailing list; it is a larger audience and it is possible you will get better advice from more knowledgeable people, including developers. If you have not posted to OpenBSD project mailing lists before, please see openbsd.org/mail.htm for guidance.
Reply With Quote
  #6   (View Single Post)  
Old 6th February 2013
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 3,116
Thanked 182 Times in 149 Posts
Default

Besides not enough mbuf clusters, it also could be that pf is hitting the limit of the state tables. See http://www.packetmischief.ca/2011/02...e-table-limit/ for an example.
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
  #7   (View Single Post)  
Old 6th February 2013
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,429
Thanked 214 Times in 189 Posts
Default

Quote:
Originally Posted by KBr View Post
To my understanding the filter on my default router (192.168.1.5) redirects outbound packets from the subnet 192.168.1.0 - say the host 192.168.1.10 - to the router 192.168.1.254 without touching them.
If your default router is OpenBSD, PF will be affected by rules or option settings affecting traffic normalization (scrub, and related rules and options). If packet reassembly is turned off in your PF configuration, PF might be blocking packet fragments which you expect to be passed. The example given in pf.conf(5) is of a fragment that can't possibly match a pass rule that uses TCP port numbers.
Quote:
Is there a way to upgrade the router directly from 5.0 to 5.2?
No. The method is to upgrade from 5.0 -> 5.1 -> 5.2. The OS upgrade process is quick and easy if you use sysmerge(8) to automate updates within /etc. Always review the upgrade guides as from time to time there are manual steps to take, such as adjusting for syntax changes within an /etc file you have customized.

To update your packages, that's as easy as # pkg_add -ui once you are on 5.2 and have updated your $PKG_PATH accordingly.

Last edited by jggimi; 6th February 2013 at 03:54 PM. Reason: clarity, more forceful statement on upgrade guides
Reply With Quote
  #8   (View Single Post)  
Old 6th February 2013
KBr KBr is offline
New User
 
Join Date: May 2012
Posts: 5
Thanked 0 Times in 0 Posts
Default

Quote:
Originally Posted by J65nko View Post
Besides not enough mbuf clusters, it also could be that pf is hitting the limit of the state tables. See packetmischief.ca/2011/02/17/hitting-the-pf-state-table-limit/ for an example.
There is no traffic at this time of day (we are a school). I will check that tomorrow. Thanks.
Reply With Quote
  #9   (View Single Post)  
Old 6th February 2013
KBr KBr is offline
New User
 
Join Date: May 2012
Posts: 5
Thanked 0 Times in 0 Posts
Default

Quote:
Originally Posted by jggimi View Post
If your default router is OpenBSD, PF will be affected by rules or option settings affecting traffic normalization (scrub, and related rules and options). If packet reassembly is turned off in your PF configuration, PF might be blocking packet fragments which you expect to be passed.
There are two statements in my pf.conf concerning this problem
set reassemble yes
match on $Ext scrub (max-mss 1440)

The latter doesn't have anything to do with my route-to rule as the related packets don't pass the external interface

Quote:
To update your packages, that's as easy as # pkg_add -ui once you are on 5.2 and have updated your $PKG_PATH accordingly.
Thanks for the hint. I will have to sync the clone of my router used as a cold stand by and the update that machine as I cannot afford any downtime of the internet gateway. It will take some days before I can do that.
Reply With Quote
Old 6th February 2013
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,429
Thanked 214 Times in 189 Posts
Default

Just to clarify the ease of upgrade.... here is a typical procedure.
  1. Read the upgrade guides for 5.1 and 5.2, taking note of any manual steps or special requirements you may have for your environment.
  2. Backup!
  3. Download the 5.1 bsd.rd RAMDISK kernel for your architecture from your nearby mirror and store in your root directory.
  4. Run sysmerge(8), pointing to etc51.tgz (and optionally xetc51.tgz) on your nearby mirror
  5. Issue a reboot(8) and select the new bsd.rd kernel.
  6. Select Upgrade at the Install/Upgrade/Shell prompt.
  7. Answer upgrade script questions, such as selecting your nearby mirror and if desired, selected filesets and kernels.
  8. Issue a reboot(8) and repeat from Step 3, using the 5.2 bsd.rd instead and the *etc52.tgz fileset(s).
  9. Once the 5.2 upgrade completes, reboot multi-user and if you have packages installed, revise your $PKG_PATH and upgrade them.
  10. If any of your packages include running daemons, you can either reboot(8) or migrate into single-user mode and then return to multi-user mode with # kill 1 followed by an # exit.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Openvpn pf/nat/route-to issue lasstoff OpenBSD Security 3 16th January 2012 12:28 PM
Multi-Path or Route-To? SlyM OpenBSD General 21 10th November 2010 07:22 PM
How to add static route using virtual NIC bsdplus Solaris 1 22nd August 2010 02:10 AM
ping: sendto: No route to host joostvgh OpenBSD General 2 29th April 2010 12:34 PM
Working dial-up connection - No Client Connection vigol FreeBSD General 5 22nd November 2009 10:59 PM


All times are GMT. The time now is 07:27 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick