How to set up ipfw for tcpmssd? - BSD

This is a discussion on How to set up ipfw for tcpmssd? - BSD ; Hello everyone, I am asking for some help to set up a minimalistic ipfw configuration to enable net/tcpmssd on my FreeBSD gateway. In an earlier thread here regarding NAT gateways I had to conclude that my problems are probably MTU ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: How to set up ipfw for tcpmssd?

  1. How to set up ipfw for tcpmssd?

    Hello everyone,

    I am asking for some help to set up a minimalistic ipfw configuration to
    enable net/tcpmssd on my FreeBSD gateway.

    In an earlier thread here regarding NAT gateways I had to conclude that my
    problems are probably MTU size related and have nothing to do with my pf
    firewall or its nat implementation.

    I was recommended to try net/tcpmssd from ports.
    Today I "make install"-ed it, and the accompanying man page clearly
    suggests that this piece of code requires the use of ipfw.

    _EXTRACT_FROM_MANPAGE_
    The following steps are necessary to run tcpmssd:
    1. Build your kernel with the following options:
    options IPFIREWALL
    options IPDIVERT
    Refer to the Handbook for detailed instructions on building a custom
    kernel.
    2. Make sure to redirect TCP traffic to the divert(4) port port. Refer
    to the ipfw(8) manual page for details.
    _END_OF_EXTRACT_

    As far as my firewall is conserned I would like to stick with pf.
    Understandably I'd also prefer to minimize what I have to learn about
    another firewall suit, but I accept the fact that I do have to learn a bit
    of ipfw in order to use tcpmssd.

    I have also learnt that combining multiple firewall suits under FreeBSD
    does work for many people to achieve the service they require. Therefore I
    assume that I should be able to keep using pf for my filtering and NAT
    requirements while adding the minimum requirements to also use ipfw for
    driving/enabling tcpmssd.

    From the man point #1 above and studying the ipfw man page +
    /sys/conf/NOTES I concluded that the best way to go is probably to add the
    following lines to my existing custom kernel config before rebuilding.
    options IPFIREWALL #required for tcpmssd
    options IPDIVERT #required for tcpmssd
    options IPFIREWALL_DEFAULT_TO_ACCEPT #default ALLOW


    Now, here is where I start to not see clearly!

    Since ipfw is compiled into my new kernel, I assume that I don't need
    firewall_enable="YES" in my rc.conf as its purpose would be to load the
    ipfw kernel module. Is that right? Or do I still need this set in order to
    enable ipfw?

    What about the complications with those ipfw sysctls?
    As far as I understand the "net.link.ether.ipfw=1" is for Layer-2, and
    because pf which I already use only works in Layer-3 these should not
    conflict. So I could safely enable this. But I believe I don't need ipfw
    in Layer-2 just to enable tcpmssd. Am I right?

    Do I need the "net.link.ether.bridge_ipfw=1" sysctl?
    I am very uncertain what this one is for. So if somebody could explain it
    (short or long, whatever you have the time and mood for), I'd be happy to
    learn.

    Most probably "net.inet.ip.fw.enable=1" is what I need. I think this is
    what triggers ipfw for all Layer-3 packets. Please correct me if (or
    rather WHEN) I am wrong!

    I will also need an ipfw config (A.K.A. rules) file, and something in it.
    And this is the point where I am absolutely clueless, also referring to
    the man paragraph #2 above.
    I assume I need a line in this config file which starts with the keyword
    "divert". But I don't know the rest. What, when, how do I divert.
    Do I need to divert everything that is TCP to tcpmssd?
    If so, how do I do that?

    You can clearly see that I tried to do as much as possible on my own, but
    I run into foggy pieces and cannot really find the good way out.
    I could really appreciate some examples, pointers, hints, etc.
    I don't expect anybody to solve my problems for me, I am more than happy
    to walk the hard way and do it myself, I just need some kick in the arse
    at certain points to keep walking.

    Best regards,
    Keve


    --
    if you need to reply directly:
    keve(at)mail(dot)poliod(dot)hu

  2. Re: How to set up ipfw for tcpmssd?

    Keve Nagy wrote:
    [snip]
    >
    > You can clearly see that I tried to do as much as possible on my own, but
    > I run into foggy pieces and cannot really find the good way out.
    > I could really appreciate some examples, pointers, hints, etc.
    > I don't expect anybody to solve my problems for me, I am more than happy
    > to walk the hard way and do it myself, I just need some kick in the arse
    > at certain points to keep walking.
    >
    > Best regards,
    > Keve


    Greetings:

    I have been sort of loosely following your saga with some interest. I
    have run dial-up for years and just this week I finally got DSL service. I
    have used ipfw, ipfilter, and within the last year, or so, pf in
    conjunction with kernel ppp (pppd). It has served me well but I am really
    liking the DSL speed (even though I only have the lowest tier package of
    768/128 and am actually seeing 864/160). So, big changes are in store for
    me. But this also entails a switch from ppp to PPPoE.

    Currently I am just running the Westell 6100 "out of the box" for a
    period to ensure everything is working as it should. This means my FreeBSD
    server/gateway/pf box is unplugged and out of service. I intend to change
    this and put it back, hence my interest in your problem. I would really
    prefer to use just the pf I have been happy with and not have to
    overcomplicate things unnecessarily. So, some thoughts/observations:

    There is a thing called Path-MTU-Discovery which sort of controls
    how/when packets get fragmented. A lot of people who don't understand it's
    necessity and utility simply block it as an undesired ICMP traffic. Not
    good. If a router somewhere out on the 'Net is misconfigured in this manner
    it is beyond your control.

    Some NIC drivers allow you to manually specify in the /etc/rc.conf on the
    ifconfig line a mtu (tack it on at the end of the line which
    configures your external interface). More than likely it won't work but it
    is something you can try first for simplicities sake. If you could plug in
    the MTU your ISP is using for PPPoE it would be really sweet.

    Next, we look at the pf configuration itself. The "scrub" parameter is
    what controls how fragments are reassembled. I noticed you were only
    using "scrub in". This is what I use here:

    scrub in all fragment reassemble
    scrub out all random-id fragment reassemble

    But what caught my curiosity was that scrub also contains a MSS directive.
    The above lines could be appended with "max-mss ". Since TCP/IPv4
    headers are 20 bytes in size MSS = MTU - 40 (both directions). Subtract 40
    from the MTU your ISP uses and set that as the MSS in pf.

    What I don't know is exactly what effect this will have. What I'm thinking
    is that it would just drop packets outside of it's parameters and maybe
    make more of a mess. This won't help. What I'm wondering is since it is
    used with scrub and reassemble maybe it might just "adjust" the packets to
    the "right" size. I'd like to know more myself and am looking to read up
    more on the subject.

    One place I have noticed the MTU-Path-Discovery and fragmentation problems
    are mostly with larger image files. A very small web site with either very
    small or no images would work OK but on sites where the images have large
    file sizes they seem to hang and not want to finish. It kind of leaves the
    page in a kind of "stuck or limbo" state.

    Since I am probably going to be experiencing some of the same kinds of
    issues as you when I attempt to put my FreeBSD box back online I have been
    researching this material of late. My main intent here is to not go down
    the messy convoluted path you are looking at, but rather hoping for a clean
    and "elegant" solution. Don't know if any of this input is even relevant or
    valuable to your situation, but I thought I'd toss it out anyways. There
    are more knowledgeable people here that maybe can clarify some stuff here,
    to the benefit of us all. :-)

    -Jason



  3. Re: How to set up ipfw for tcpmssd?

    Hi Jason,
    Cheers for the large amount of info you provided!

    > I have used ipfw, ipfilter, and within the last year, or so, pf in
    > conjunction with kernel ppp (pppd). It has served me well but I am really
    > liking the DSL speed (even though I only have the lowest tier package of
    > 768/128 and am actually seeing 864/160). So, big changes are in store for
    > me. But this also entails a switch from ppp to PPPoE.


    Not really. You will be just fine with ppp on ADSL as well. pppd can do
    PPPoE for you, and you only need to do some extremely easy and quick
    modification of your /etc/ppp.conf. You can even keep your dial-up
    settings in place for emergency connections and add some extra lines for
    daily use with DSL.
    In fact, this is the solution I will revert back to and I am convinced
    that it will also solve my tcpmssd/MTU problem plus another issue related
    to routing. Some months ago I already used this method and it worked at
    that time, but then I reinvented the wheel and thought to find a much
    better way to do things. By now I realised that it generated issues that I
    would have never considered before, in fact I believed that it will
    simplify my life.

    Well, I will go back to this FreeBSD PPPoE with pppd method and see if it
    solves my problems. I am confident that it will. In theory it should
    completely eliminate the need to use tcpmssd, therefore also the necessity
    to add ipfw to the system so that pf alone can do its filtering and NAT
    job (without the need for natd, which is another point here).
    End of weekend, workdays are coming so I will not have much time to do
    this, but once I am done I will leave feedback here. I estimate about 3
    days, but next weekend the latest that I will need until I complete the
    test and prove the theory in practice.
    After that I am more than happy to help you with the setup of PPPoE using
    natd. That is very easy and you will love it. Doesn't take more than 6
    minutes at most.

    > There is a thing called Path-MTU-Discovery which sort of controls
    > how/when packets get fragmented. A lot of people who don't understand it's
    > necessity and utility simply block it as an undesired ICMP traffic. Not
    > good. If a router somewhere out on the 'Net is misconfigured in this manner
    > it is beyond your control.


    This part I have already learnt.
    The hard way, of course. :-)

    > Some NIC drivers allow you to manually specify in the /etc/rc.conf on the
    > ifconfig line a mtu (tack it on at the end of the line which
    > configures your external interface). More than likely it won't work but it
    > is something you can try first for simplicities sake. If you could plug in
    > the MTU your ISP is using for PPPoE it would be really sweet.


    I might not need to do that. PPPoE related configuration in /etc/ppp.conf
    allows me to set the MTU size for pppd, so that should work. I will let
    you know!

    > Next, we look at the pf configuration itself. The "scrub" parameter is
    > what controls how fragments are reassembled. I noticed you were only
    > using "scrub in". This is what I use here:
    >
    > scrub in all fragment reassemble
    > scrub out all random-id fragment reassemble


    I will study the pf faq again and see about this.
    I don't really see that your "scrub out" line helps me in any way at this
    moment. Maybe after that re-study I will.

    > But what caught my curiosity was that scrub also contains a MSS directive.
    > The above lines could be appended with "max-mss ". Since TCP/IPv4
    > headers are 20 bytes in size MSS = MTU - 40 (both directions). Subtract 40
    > from the MTU your ISP uses and set that as the MSS in pf.


    Hmn, this managed to avoid my attention until now. Nice catch, Jason!
    I will also study it in more details, but at this moment I am not
    convinced that it helps me.

    > What I don't know is exactly what effect this will have. What I'm thinking
    > is that it would just drop packets outside of it's parameters and maybe
    > make more of a mess. This won't help.


    That is exactly what I am afraid of.

    > What I'm wondering is since it is
    > used with scrub and reassemble maybe it might just "adjust" the packets to
    > the "right" size. I'd like to know more myself and am looking to read up
    > more on the subject.


    So this is yet to be proven in practice.
    I will also try to read up on this. Let me know if you found the relevant
    details before I do, please!

    > One place I have noticed the MTU-Path-Discovery and fragmentation problems
    > are mostly with larger image files. A very small web site with either very
    > small or no images would work OK but on sites where the images have large
    > file sizes they seem to hang and not want to finish. It kind of leaves the
    > page in a kind of "stuck or limbo" state.


    I can confirm this.
    Although, I had issues with one specific site where there were no large
    images at all.

    > Since I am probably going to be experiencing some of the same kinds of
    > issues as you when I attempt to put my FreeBSD box back online I have been
    > researching this material of late. My main intent here is to not go down
    > the messy convoluted path you are looking at, but rather hoping for a clean
    > and "elegant" solution.


    I might be able to help you with that.
    And I am more than happy to, as long as you require any help of course.

    > Don't know if any of this input is even relevant or
    > valuable to your situation, but I thought I'd toss it out anyways.


    I also prefer to discuss my issues in the newsgroup. At the first place
    because it quickly and efficiently helps/improves me. And second, because
    it can also benefit other people reading the newsgroup or later searching
    the webarchives in this topic.

    > There
    > are more knowledgeable people here that maybe can clarify some stuff here,
    > to the benefit of us all. :-)


    Yeah, well. The trich with them is that you need to learn to actually
    listen to them instead of chasing your own ghost-ideas. Most of the time
    it helps. :-)
    Although I have to emphasize that there were occassions when I got my
    satisfaction by not abandoning my ghost-idea when everybody else told me
    to and I didn't start to walk the way that already proved to be good to
    everybody else. This sometimes can lead to discovering a shorter, nicer or
    easier way. (but many times, not!)

    Best regards,
    Keve

    --
    if you need to reply directly:
    keve(at)mail(dot)poliod(dot)hu

  4. Re: How to set up ipfw for tcpmssd?

    Keve Nagy wrote:
    >
    > Not really. You will be just fine with ppp on ADSL as well. pppd can do
    > PPPoE for you, and you only need to do some extremely easy and quick
    > modification of your /etc/ppp.conf.


    I have not read and understood the full issues, but in case it has not
    been mentioned previously, let me mention that there is another way to
    do kernel mode ppp, compatible with pppoe, it is to use the port
    net/mpd. This uses the netgraph system and in particular ng-pppoe. This
    system has certainly a command to fix the MTU, i see in the
    documentation "set iface mtu value". There is also a tcpmmsfix option
    which does what your tcpmssfix program doesn't for you. It was my
    understanding that this was the standard way to do pppoe on FreeBSD. I
    have seen old benchmarks showing that user mode ppp was totally
    inadequate for ADSL speeds and that kernel mode via netgraph was
    correct. But i have never used personnally this system, because i have a
    cheap Linksys box (Linux based) which works very well for me, with 0
    configuration :-(

    You can see a config file using mtu fixes here:
    http://www.bsdmon.com/rub/2005/03/29/howto

    --

    Michel TALON


  5. Re: How to set up ipfw for tcpmssd?

    Michel Talon wrote:

    > Keve Nagy wrote:
    >>
    >> Not really. You will be just fine with ppp on ADSL as well. pppd can do
    >> PPPoE for you, and you only need to do some extremely easy and quick
    >> modification of your /etc/ppp.conf.

    >
    > I have not read and understood the full issues, but in case it has not
    > been mentioned previously, let me mention that there is another way to
    > do kernel mode ppp, compatible with pppoe, it is to use the port
    > net/mpd. This uses the netgraph system and in particular ng-pppoe. This
    > system has certainly a command to fix the MTU, i see in the
    > documentation "set iface mtu value". There is also a tcpmmsfix option
    > which does what your tcpmssfix program doesn't for you. It was my
    > understanding that this was the standard way to do pppoe on FreeBSD. I
    > have seen old benchmarks showing that user mode ppp was totally
    > inadequate for ADSL speeds and that kernel mode via netgraph was
    > correct. But i have never used personnally this system, because i have a
    > cheap Linksys box (Linux based) which works very well for me, with 0
    > configuration :-(
    >


    I had seen the benchmarks you describe quite a number of years ago, but
    could not recall which was the better. Since I am a fan of keeping network
    related stuff in kernel space and mpd seems to be the better approach I may
    give it a go if need be. I found a link to a howto page which also contains
    a reference to that old benchmark article:

    http://www.shellbang.org/freebsd/mpdpf.html

    My Westell 6100 DSL modem/router thingy is OK for 10/100 Ethernet and if my
    LAN was this speed I'd just plug a hub/switch to it and be done. My problem
    is I use Gigabit Ethernet and don't want to drop that on my internal LAN.

    I have two approaches to try whenever I get around to it. One is what they
    call "IP Passthrough" and the other to simply change it to bridge mode.

    IP passthrough leaves all the auth/connection stuff to be handled by the
    modem and just places the WAN IP on the NIC of the FreeBSD router/gateway
    box. I believe this might work with the exception of what happens when the
    ISP changes the external DHCP lease on the WAN side. I don't understand how
    the lease will propagate into the FreeBSD box. What I'm guessing is that it
    will work up until lease renewal and then quit. But it is the easier change
    to revert backwards from.

    Bridge mode will require some form of full blown PPPoE on the 'fbsd box.
    What I didn't want to use was userland ppp. If I have to go this route I am
    definitely going to take a look at mpd.

    Thank you greatly for reminding me of this! :-)

    -Jason



  6. Re: How to set up ipfw for tcpmssd?

    Keve Nagy wrote:

    > Hi Jason,
    > Cheers for the large amount of info you provided!
    >
    >> I have used ipfw, ipfilter, and within the last year, or so, pf in
    >> conjunction with kernel ppp (pppd). It has served me well but I am really
    >> liking the DSL speed (even though I only have the lowest tier package of
    >> 768/128 and am actually seeing 864/160). So, big changes are in store for
    >> me. But this also entails a switch from ppp to PPPoE.

    >
    > Not really. You will be just fine with ppp on ADSL as well. pppd can do
    > PPPoE for you, and you only need to do some extremely easy and quick
    > modification of your /etc/ppp.conf. You can even keep your dial-up
    > settings in place for emergency connections and add some extra lines for
    > daily use with DSL.


    Yes the modem and phone line is still there and will be saved as a backup.

    > In fact, this is the solution I will revert back to and I am convinced
    > that it will also solve my tcpmssd/MTU problem plus another issue related
    > to routing. Some months ago I already used this method and it worked at
    > that time, but then I reinvented the wheel and thought to find a much
    > better way to do things. By now I realised that it generated issues that I
    > would have never considered before, in fact I believed that it will
    > simplify my life.


    I'm a firm believer in the "KISS" principle. Also the first rule of
    maintenance: If it ain't broke don't fix it. Second rule: Hit it with
    progressively larger hammers until it gets destroyed and you need a new
    one. :-)

    >
    > Well, I will go back to this FreeBSD PPPoE with pppd method and see if it
    > solves my problems. I am confident that it will. In theory it should
    > completely eliminate the need to use tcpmssd, therefore also the necessity
    > to add ipfw to the system so that pf alone can do its filtering and NAT
    > job (without the need for natd, which is another point here).
    > End of weekend, workdays are coming so I will not have much time to do
    > this, but once I am done I will leave feedback here. I estimate about 3
    > days, but next weekend the latest that I will need until I complete the
    > test and prove the theory in practice.
    > After that I am more than happy to help you with the setup of PPPoE using
    > natd. That is very easy and you will love it. Doesn't take more than 6
    > minutes at most.
    >


    See my reply to Michel Talon for more on this area.

    [snip]
    >> Next, we look at the pf configuration itself. The "scrub" parameter is
    >> what controls how fragments are reassembled. I noticed you were only
    >> using "scrub in". This is what I use here:
    >>
    >> scrub in all fragment reassemble
    >> scrub out all random-id fragment reassemble

    >
    > I will study the pf faq again and see about this.
    > I don't really see that your "scrub out" line helps me in any way at this
    > moment. Maybe after that re-study I will.


    The main reason was the security enhancement of . Also, in
    addition, while my internal Ethernet uses the usual 1500 MTU the dial up
    ISP provider I had was using an MTU of 1524.


    [snip]
    >
    > I also prefer to discuss my issues in the newsgroup. At the first place
    > because it quickly and efficiently helps/improves me. And second, because
    > it can also benefit other people reading the newsgroup or later searching
    > the webarchives in this topic.
    >

    [snip]
    >
    > Yeah, well. The trich with them is that you need to learn to actually
    > listen to them instead of chasing your own ghost-ideas. Most of the time
    > it helps. :-)


    This is actually a fairly professional Newsgroup. I have been reading it for
    something like 6 years now and enjoy it immensely.

    > Although I have to emphasize that there were occassions when I got my
    > satisfaction by not abandoning my ghost-idea when everybody else told me
    > to and I didn't start to walk the way that already proved to be good to
    > everybody else. This sometimes can lead to discovering a shorter, nicer or
    > easier way. (but many times, not!)
    >


    True enough! Sometimes this leads to a newer and better way to accomplish
    something with the possibility of superior performance as well. Whenever
    one stumbles upon something like this it is good to write it up somewhere
    so other people don't have to "reinvent the wheel".

    -Jason

    [snip]



  7. Re: How to set up ipfw for tcpmssd?

    Jason Bourne wrote:
    > My Westell 6100 DSL modem/router thingy is OK for 10/100 Ethernet and if my
    > LAN was this speed I'd just plug a hub/switch to it and be done. My problem
    > is I use Gigabit Ethernet and don't want to drop that on my internal LAN.


    And, where is the problem with that?
    I also have Gigabit speed on the Lan, and only the cheapest 512k/96k DSL
    connection to the rest of the world.
    I have a Gigabit switch, all the hosts on the lan have gigabit nics,
    including the gateway/firewall machine. This latter has another nic, a
    cheaper 10/100 model, and that is connected to my DSL modem.
    There you are!
    Gigabit speed within the LAN, and DSL speed to the internet.
    Although I had to use expensive Cat6 SFTP cabling in order to truelly meet
    Gigabit speed as with lower quality Cat5e connections in the way packages
    were frequently dropped.

    > I have two approaches to try whenever I get around to it. One is what they
    > call "IP Passthrough"


    This is what my modem calls half-bridge mode A.K.A pseudo-bridge mode.
    And this is where I made the mistake from which I was just trying to
    recover. In my experience this mode is not good. It appeared to be simpler
    and smarter to use, but it generated issues that troubled me for quite
    some time before I recognised the source.


    > and the other to simply change it to bridge mode.


    This is what I just reverted back to.
    I think I will be more happy with this. I use it with user-ppp (PPPoE).

    > IP passthrough leaves all the auth/connection stuff to be handled by the
    > modem and just places the WAN IP on the NIC of the FreeBSD router/gateway
    > box. I believe this might work with the exception of what happens when the
    > ISP changes the external DHCP lease on the WAN side. I don't understand how
    > the lease will propagate into the FreeBSD box.


    In my case the BSD box had to get the routable IP from the modem via DHCP.
    The shorter you set the lease time the more frequently the lease is
    renewed (requested), therefore you can pick up a new lease in every 5
    minutes which guarantees you that in case of IP change your system is
    disconnected for 4:59 at most.
    Also, my modem can do remote logging via syslogd. So I planned to log to
    my bsd box's syslogd and catch the IP-change event message upon which a
    script could have forcibly renew the DHCP address.

    > Bridge mode will require some form of full blown PPPoE on the 'fbsd box.
    > What I didn't want to use was userland ppp. If I have to go this route I am
    > definitely going to take a look at mpd.


    I do use user-ppp via /etc/ppp/ppp.conf. It works well for me.
    But when I have the time I will probably also try mpd. For the time being
    however, I am happy with user-ppp.

    Regards,
    Keve

    --
    if you need to reply directly:
    keve(at)mail(dot)poliod(dot)hu

  8. pf+nat problem (MTU) solved

    Hi Everyone,

    As described in earlier posts here and also in some private e-mails to
    some of you, I made some changes on my system last night.
    I abandoned the idea of getting tcpmmsd to work by adding ipfw to the
    system which currently uses pf. A little thinking made me realise that my
    probable MTU size problem is all originating from me deciding earlier to
    use the DSL modem in half-bridge mode instead of transparent-bridge mode.

    The first one does PPPoE inside the modem, handles connection and
    authentication to the ISP, and offers the routable public IP via DHCP to a
    host connecting to the LAN port of the modem.
    The latter mode is simply a bridge modem, so you need to use an OS level
    PPPoE solution with that to connect, authenticate, receive the routable
    IP, etc.

    I wanted to use the first method, but by now I recognised that it
    generates MTU size and route related problems.

    Now I switched back to using the modem as a true bridge-modem. I use
    user-ppp and in /etc/ppp/ppp.conf I set the max MTU size so that upon
    connection my tun0 device will look like this:
    tun0: flags=8051 mtu 1492
    inet xxx.yy.100.141 --> xxx.yy.109.4 netmask 0xffffffff
    Opened by PID 1016
    (tun0 is on rl0)
    Whereas with the earlier modem-mode and DHCP the device connecting to the
    modem showed:
    rl0: flags=8843 mtu 1500
    options=8
    inet kk.mmm.205.206 netmask 0xffffffff broadcast kk.mmm.205.206
    ether 00:30:18:a0:53:6a
    media: Ethernet autoselect (100baseTX )
    status: active

    You can see the difference in the MTU value, as well as in the inet line
    which improves my external routing.

    So now that the MTU is not an issue any more, everything should work
    without ipfw and tcpmssd being used.

    Guess what!
    It didn't work. :-)

    I experienced the very same connection problems from behind the NAT
    gateway as before. The majority of websites worked fine, but for example
    www.kekalma.hu took extremely long to show up and www.randivonal.hu
    timeouts without showing a tiny piece of the site.

    So I concluded that my issue may not be MTU related after all, and I
    started to turn my attention to pf.

    I created an open firewall configuration where there is no scrub, the NAT
    rules are all enabled, and the only filter rule is "pass all".
    With this in effect, everything worked fine behind the NAT.
    The two websites mentioned above downloaded perfectly fine with no delay
    at all.

    I started to put extra rules back to the ruleset, made some awkward tests
    and finally concluded where my problem was.
    My full-grown ruleset is based on a default deny as follows.
    +Macros here.
    +Tables here.
    +Options here.
    +NAT and RDR rules here + FTP proxy.
    Scrub in
    #and here start the filter rules as:
    block in
    pass out keep state
    pass in quick on $int_if
    +some drop quick rules here

    You will never guess, but the trouble was caused by the "pass out keep
    state" line. When I tried "pass out" instead and "pass in on $ext_if inet
    proto {tcp udp icmp}" it worked fine.

    With some more testing I narrowed it down and now believe that for some
    reason, the double-stateful package inspection is that causes problems
    with the above mentioned few websites.
    I still don't get why it works for the majority of sites and causes
    trouble with these few, but here is what I use now:
    block in
    ##pass out keep state #replaced by the next two line
    pass out on $ext_if inet keep state
    pass out on $int_if #so no state condition here
    ....

    And now everything works.
    I am still not convinced that it is not related to MTU however.
    I also don't get why the keep state on both the ext and int if didn't work
    for these few sites while it did work for everything else.
    And finally, I also don't know how much security risk the new changes mean.
    If you know anything about any of these, your comments are welcome!

    Regards,
    Keve


    --
    if you need to reply directly:
    keve(at)mail(dot)poliod(dot)hu

  9. Re: How to set up ipfw for tcpmssd?

    [snip]

    > Jason Bourne wrote:
    >> My Westell 6100 DSL modem/router thingy is OK for 10/100 Ethernet and if
    >> my LAN was this speed I'd just plug a hub/switch to it and be done. My
    >> problem is I use Gigabit Ethernet and don't want to drop that on my
    >> internal LAN.

    >
    > And, where is the problem with that?


    I use Jumbo frames. Don't even want to mess with Jumbo and regular Ethernet
    MTU crap. I intend to keep the two far apart, hence the main reason to get
    the FreeBSD gateway back online. One thing that I got real lucky about: I
    noticed on the DSL/WAN side Verizon uses an MTU of 1540. 1540 - 40 = 1500
    (the internal Ethernet LAN side). Someone was really smart when they did
    this!

    [snip]
    >
    >> I have two approaches to try whenever I get around to it. One is what
    >> they call "IP Passthrough"

    >
    > This is what my modem calls half-bridge mode A.K.A pseudo-bridge mode.
    > And this is where I made the mistake from which I was just trying to
    > recover. In my experience this mode is not good. It appeared to be simpler
    > and smarter to use, but it generated issues that troubled me for quite
    > some time before I recognised the source.


    I've added a second NIC to my FreeBSD 6.1 gateway/server box and
    successfully switched to "IP-Passthrough" mode. Been up a little over a day
    now. Everything seems to be doing just fine. Disabled the NAT and Firewall
    in the Westell and am using the pf in the FreeBSD box. Seems to be working
    well so far. :-)

    [snip]

    -Jason



+ Reply to Thread