Gateway problem
I'm having a strange situation for quite sometime. I have two external interfaces one of which is an ADSL interface tun0 and obtains IP address dynamically and the other is a (xl1) leased line which has a static global IP address, lets say 212.64.212.180. Both interfaces access internet without any problem. Recently I've configured qmail on this system to send out email thru xl1 interface and use ADSL only for web traffic. It used to work quite good for a while but recently I noticed TCP packets have been going out from tun0 and responses coming in thru xl1. tun0 and ADSL is the default gateway. But the TCP packets are bound to 212.64.212.180 IP address which should send them out thru xl1. But it doesn't. For the test, I did these tcpdump -nt -i xl1 tcp & telnet -s 212.64.212.180 smtp.tnet.com 25 connection establishes but I can see only the TCP response packets coming from xl1, like the following x.y.z.t > 212.64.212.180 x.y.z.t > 212.64.212.180 All from external IPs to my xl1 int. No packets going out from xl1 they all go thru default gateway even if TCP connections are bound to xl1's IP address. I'd like to know if anybody knows why this happened and I can I turn things back the way they were. Any help would be much appreciated. My configuration is like this; FreeBSD 5.4-RELEASE ipf: IP Filter: v3.4.35 (336) Kernel: IP Filter: v3.4.35 ipfw has no rules; allow ip from any to any there's also a transparent proxy setup for squid #~>netstat -rn Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default88.234.8.1 UGS 0 78722302 tun0 10/24 link#1 UC 00rl0 => 10 10.1.1.222 UGS 026233xl0 10.0.0.99 link#1 UHLW04rl0 10.1.1/24 link#2 UC 00xl0 10.1.1.13 00:50:8d:ed:88:94 UHLW0 1876xl0 1118 10.1.1.222 00:01:02:df:c1:19 UHLW1 689lo0 10.1.1.225 00:b0:d0:20:b7:9e UHLW096690xl0706 88.234.8.1 88.234.14.26 UH 10 tun0 127.0.0.1 127.0.0.1 UH 0 2305904lo0 192.168.0/16 link#3 UCS 00xl1 212.64.212.176 ff:ff:ff:ff:ff:ff UHLWb 0 15xl1 => 212.64.212.176/29 link#3 UC 00xl1 212.64.212.180 00:04:76:9b:3d:f8 UHLW0 125lo0 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
PFIL hooks etc.
I'm looking at some changes to the pfil and ipfw code. I notice that the pfil changes for link layer and bridge based filtering have not been completed yet.. (by which I mean that ipfw is still called directly from those places rather than via pfil. Is anyone working on this? I have been playing around with filtering bridges and notice that there is no way for pfil to tell the called modules (e.g. ipfw) that it was called from a bridge as opposed to having been called from the ethernet framework. I see two possible ways this could be done. 1/ adding a filter list head with a different KEY/KEYTYPE for example adding a third keytype: #define PFIL_TYPE_AF1 /* key is AF_* type */ #define PFIL_TYPE_IFNET 2 /* key is ifnet pointer */ #define PFIL_TYPE_BRIDGE3 /* key is ignored. Used for bridging */ and making a special filter list for bridging. It would be possible to use the ifnet associated with the bridge I guess but it would be hard to find the right queue if you didn't know where the ifnet for the bridge was. Possibly another way would be to extend the flags sent with each packet do contain more than just the direction: #define PFIL_OUT 0x0002 #define PFIL_WAITOK0x0004 #define PFIL_ALL (PFIL_IN|PFIL_OUT) +#define PFIL_DIR (PFIL_IN|PFIL_OUT) +#define PFIL_IPSTACK 0x0010 +#define PFIL_BRIDGE0x0020 +#define PFIL_LINK 0x0030 +#define PFIL_CALLER0x00F0 thus (flags & PFIL_CALLER) can be tested to see who called you. and (flags & PFIL_DIR) can be tested to get the direction. thoughts? Julian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PFIL hooks etc.
On Saturday 21 October 2006 00:57, Julian Elischer wrote: > I'm looking at some changes to the pfil and ipfw code. > > I notice that the pfil changes for link layer and bridge based > filtering have not been completed yet.. > (by which I mean that ipfw is still called directly > from those places rather than via pfil. Is anyone working on this? > I have been playing around with filtering bridges and > notice that there is no way for pfil to tell the > called modules (e.g. ipfw) that it was called from a bridge as opposed > to having been called from the ethernet framework. > > I see two possible ways this could be done. > 1/ adding a filter list head with a different KEY/KEYTYPE >for example > adding a third keytype: > > #define PFIL_TYPE_AF1 /* key is AF_* type */ > #define PFIL_TYPE_IFNET 2 /* key is ifnet pointer */ > #define PFIL_TYPE_BRIDGE3 /* key is ignored. Used for bridging > */ > > and making a special filter list for bridging. It would be possible > to use the ifnet associated with the bridge I guess but it would be > hard to find the right queue if you didn't know where the ifnet > for the bridge was. > > Possibly another way would be to extend the flags sent > with each packet do contain more than just the direction: > > #define PFIL_OUT 0x0002 > #define PFIL_WAITOK0x0004 > #define PFIL_ALL (PFIL_IN|PFIL_OUT) > +#define PFIL_DIR (PFIL_IN|PFIL_OUT) > +#define PFIL_IPSTACK 0x0010 > +#define PFIL_BRIDGE0x0020 > +#define PFIL_LINK 0x0030 > +#define PFIL_CALLER0x00F0 > > > thus (flags & PFIL_CALLER) can be tested to see who called you. > and (flags & PFIL_DIR) can be tested to get the direction. > > thoughts? Andre has a WIP for this. I'll let him speak. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpQSe85EeR6q.pgp Description: PGP signature
Gigabit performance test
Hello, I am preparing a test of different FreeBSD firewalls in our lab, before doing so I am trying to push maximum 2 gbps of traffic through the machine with a simple routed on it in the most optimal way. The lab setup is as following: 4 x traffic generators machines: Dual Opteron, generic FreeBSD 6.1 / AMD64 kernel + iperf 2.02. The iperf between the machines directly is almost always around ~930 megabit, which is fine (See table referenced later for detailed results). 1 x Firewall machine, which is a Dell 2650 Server, for detailed specs please see: dmesg: http://www.codeangels.com/misc/fwtest/first/fw_dmesg.txt pciconf: http://www.codeangels.com/misc/fwtest/first/fw_pciconf.txt sysctl: http://www.codeangels.com/misc/fwtest/first/fw_sysctl.txt kernel: http://www.codeangels.com/misc/fwtest/first/fw_kern.txt HZ and Pooling values in those config files have been changed by me during test several times as you will see in results table. The kernels have pf compiled in but it is not turned on at this time. The network topo is: http://www.codeangels.com/misc/fwtest/first/topo.gif And here are the results: http://www.codeangels.com/misc/fwtest/first/results.htm My questions are: * Single stream / single thread is always slower then in direct machine to machine communication, full throughput is reached only with multiple threads. Why? * In polling mode, there seems to be a "magic wall" between 1.3 and 1.7gbps where INT CPU usage suddenly jumps up from almost nothing to over 45+ and throughput stops there, Why? Can this be changed? * Any other ideas on improving performance of this box? Thanks ahead for help! Kirill ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
more on pfil and bridging
The more I look at this the more I think that it is broken. Instead of the bridge registering a separate filter queue for itself, it is using the queues set up by the IP stack. It should register its own stack and each filter type should register their own filter functions for that level on the stack. is there a reason that this is not done? If the answer is simply ENOTIME then I will volunteer to go through it and do it properly. suggested changes: I propose to create filter queues for if_ethersubr.c and if_bridge.c distinguished by slightly different keys. I also propose to rename inet_pfil_hook to be inet_pfil_head (or inet_pfil_hooks). I would also look at following the documentation by seeing whether we shouldn't be using a DLT/KEY instead of PFIL_AF and AF_INET as the key type/key. The Direction argument should be expanded to be a generic 'flags' argument where two of the flags are direction. Other flags can be: WAIT_OK:(It's already defined to be there) HOST_ORDER: Fields in the header have been swapped to host order. The ipfw code would supply different entry points for bridge and Ethernet supplied packets. the ipfw args struct should grow a 'flags' field that can indicate (for example) that the IP header fields have not been put in host order (or have) and that the packet is from a bridge rather than just being layer2. ipfw would grow a 'bridge' keyword to check that flag. Julian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PFIL hooks etc.
Max Laier wrote: Andre has a WIP for this. I'll let him speak. It doesn't appear to be in P4 that I have spotted.. I'll wait to hear from him but now I see how pfil works I can see what needs to be done and can do it if required. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: more on pfil and bridging
On Saturday 21 October 2006 03:28, Julian Elischer wrote: > The more I look at this the more I think that it is broken. > > Instead of the bridge registering a separate filter queue for itself, > it is using the queues set up by the IP stack. > > It should register its own stack and each filter type should > register their own filter functions for that level on the stack. > > is there a reason that this is not done? If the answer is simply > ENOTIME then I will volunteer to go through it and do it properly. I guess so. > suggested changes: > > I propose to create filter queues for if_ethersubr.c and if_bridge.c > distinguished by slightly different keys. I also propose to rename > inet_pfil_hook to be inet_pfil_head (or inet_pfil_hooks). > > I would also look at following the documentation by seeing whether > we shouldn't be using a DLT/KEY instead of PFIL_AF and AF_INET > as the key type/key. I think if_ethersubr.c and if_bridge.c should pass to the same pfil hook. And I'd vote for the current - very sophisticated - if_bridge.c filtering to stay, at least as opt-in. Otherwise it will be tricky to support stateful filtering in pf on transparent bridges. > The Direction argument should be expanded to be a generic 'flags' > argument where two of the flags are direction. > Other flags can be: > WAIT_OK: (It's already defined to be there) > HOST_ORDER: Fields in the header have been swapped to host order. > > The ipfw code would supply different entry points for bridge > and Ethernet supplied packets. > > the ipfw args struct should grow a 'flags' field that can > indicate (for example) that the IP header fields have not been > put in host order (or have) and that the packet is from a bridge > rather than just being layer2. > > ipfw would grow a 'bridge' keyword to check that flag. I don't think that is necessary. Right now we also have a mode to pass bridged packets as "normal" L2 packets. ipfw doesn't discriminate between packets from if_ethersubr.c and if_bridge.c - and I don't see why it should. If discrimination is required one can still fall back on the L3decap in if_bridge.c - see above. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgp2WTGEq3PCX.pgp Description: PGP signature
Re: Gigabit performance test
On Sat, 21 Oct 2006 03:17:40 +0200 (CEST), in sentex.lists.freebsd.net you wrote: > >dmesg: http://www.codeangels.com/misc/fwtest/first/fw_dmesg.txt >pciconf: http://www.codeangels.com/misc/fwtest/first/fw_pciconf.txt >sysctl: http://www.codeangels.com/misc/fwtest/first/fw_sysctl.txt >kernel: http://www.codeangels.com/misc/fwtest/first/fw_kern.txt Are you using amd64 or i386 kernel ? the config implies you are using i386 > >HZ and Pooling values in those config files have been changed by me during >test several times as you will see in results table. >The kernels have pf compiled in but it is not turned on at this time. > >The network topo is: http://www.codeangels.com/misc/fwtest/first/topo.gif >And here are the results: >http://www.codeangels.com/misc/fwtest/first/results.htm > >* Any other ideas on improving performance of this box? I found kern.polling.idle_poll=1 to improve performance in polling. Also, try updating the box to 6.2 first as there are quite a few improvements to the em driver You can also fiddle with assigning less to userspace with kern.polling.user_frac=30 Don remember for sure, but ipfw seemed to be a bit faster that pf. Also with no firewall loaded there seemed to be quite a bit more throughput... However, that kind of defeats the purpose of a firewall. Also, did you try without polling in the kernel ? The way the updated em driver works should negate the need for kernel polling as well. Also if you dont use INET6 or ipsec, I would remove them from the kernel ---Mike Mike Tancsa, Sentex communications http://www.sentex.net Providing Internet Access since 1994 [EMAIL PROTECTED], (http://www.tancsa.com) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Avoiding natd overhead
I'm working with a FreeBSD-based router that's using IPFW for policy routing, traffic shaping, and transparent proxying and natd for network address translation. IPFW does these things pretty well (in fact, I don't know if another firewall, like pf, could even do some of these things I'm doing with IPFW), but natd is by far the most CPU-intensive process on the system and is causing it to crumple like a wet towel under heavy loads. How can I replace just the functionality of natd without moving to an entirely new firewall? Can I still select which packets are routed to the NAT engine, and when this occurs during the processing of the packet? --Brett Glass ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
