Re: Mysterious packets with stateful ipfw+nat
On Sat, Dec 02, 2006 at 09:00:13PM +0100, Max Laier wrote:
On Saturday 02 December 2006 19:00, James Halstead wrote:
Ok, the obvious part that I think I was missing while it was late,
was that these must be keep-alive packets generated by the firewall as
the dynamic rules are about to expire. That being the case however,
shouldn't these keep-alive packets take the same action as the original
rule (skipto 1000 and be diverted through NAT for processing)?
keep-alive packets are marked with M_SKIP_FIREWALL in
netinet/ip_fw2.c::send_pkt You could try to remove that, rebuild and see
if it helps. I'm not sure what the reasoning behind this setting was and
have no idea what implications it has to change it. If it helps your
setup we might want to consider a sysctl to change that behavior.
if i remember well, the M_SKIP_FIREWALL is because otherwise they
would reset the timer for the session as if a reply had come from
the other side.
i understand that this makes the interaction with nat a bit problematic.
On te other hand, i don't have a better solution.
cheers
luigi
James Halstead wrote:
Ok, this has been driving me nuts for a while. I recently noticed
that my 5.4-RELEASE firewall was having a problem with packet
leakage. I am seeing the occasional packet on the outside interface
with an internal src ip. I put a hub between my firewall and cable
modem and verified that the packets are indeed on the wire. Now I am
in the process of setting up a new 6.1-RELEASE box and the same issue
was happening on my test network.
So far I don't get it. I must be missing something obvious. At least
everything still works in general.
The test setup is a clean install of 6.1-RELEASE, using GENERIC with
the ipfw.ko and ipdivert.ko modules loaded. After searching around I
was basing the configuration off of:
http://lists.freebsd.org/mailman/htdig/freebsd-ipfw/2004-June/001182.
html
The test box has two Ethernet interfaces, renamed to be isp0 and
net0. isp0 is using DHCP, and receives the address 10.42.0.220/24.
net0 is running a DHCP server, and sits on 192.168.1.1/24. There is
one single piece of hardware on net0 which is always assigned
192.168.1.230. The gateway to the actual Internet sits on
10.42.0.254. A pretty simple setup.
The internal machine is just constantly connecting to an external web
server to generate traffic. I see the same basic type of thing happen
for other usage as well on my main network (ssh sessions, https/http
sessions, etc). When looking at tcpdump I am occasionally seeing (on
isp0):
19:35:27.591761 aa:aa:aa:5b:db:99 bb:bb:bb:1f:33:da,
192.168.1.230.2542 xx.xx.53.84.80: ., cksum 0xfade (correct),
2295591733:2295591733(0) ack 167570634 win 0
If this packet was truly supposed to be going out on the external
interface, it should have gone through NAT and show a src ip of
10.42.0.220. To make it more frustrating, even if I enable ifpfw at
layer 2, I am unable to capture these rogue packets. If I watch
tcpdump on net0 at the same time, I see the following:
19:35:27.591767 aa:aa:aa:5b:db:98 cc:cc:cc:10:04:ce,
xx.xx.53.84.80 192.168.1.230.2542: ., cksum 0xfade (correct),
913:913(0) ack 1256 win 0
The only other thing that I have noticed, is that the packets seem to
show up on the external interface at about the same time as the
dynamic rules expire. The dynamic rule would look like:
192.168.1.230 2542 - xx.xx.53.84 80
Which is pretty much what I would expect. The same setup with a
non-stateful ipfw ruleset (using established keyword) doesn't seem to
have this problem. Any ideas? configuration follows.
natd.conf
unregistered_only yes
dynamic yes
#deny_incoming yes
log_denied yes
log_ipfw_denied yes
(deny_incoming was set, turned it off to see if it helped but it
works the same).
* ipfw.rules
# Test stateful firewall + natd script
cmd=/sbin/ipfw add
natout=skipto 1000
oif=isp0
iif=net0
inet=192.168.1.0/24
NOROUTE=( 172.16.0.0/12 or 192.168.0.0/16 or \
0.0.0.0/8 or 169.254.0.0/16 or 192.0.2.0/24 or 224.0.0.0/4 or
240.0.0.0/4 )
# Start with a clean ruleset
/sbin/ipfw -q -f flush
# Allow all traffic on the loopback and internal network, to keep
this simple.
$cmd 2 allow all from any to any via lo0
$cmd 5 allow all from any to any in via $iif
$cmd 6 allow all from any to any out xmit $iif
# Translate incoming traffic here
$cmd 200 divert natd ip from any to any in via $oif
$cmd 205 check-state
# Outbound
# Use stateful inspection to allow any connection from the internal
network.
$cmd 300 $natout tcp from any to any out via $oif setup keep-state
$cmd 305 $natout udp from any to any out via $oif keep-state
$cmd 310 $natout icmp from any to any out via $oif
Re: Mysterious packets with stateful ipfw+nat
Luigi Rizzo wrote: On Sat, Dec 02, 2006 at 09:00:13PM +0100, Max Laier wrote: On Saturday 02 December 2006 19:00, James Halstead wrote: Ok, the obvious part that I think I was missing while it was late, was that these must be keep-alive packets generated by the firewall as the dynamic rules are about to expire. That being the case however, shouldn't these keep-alive packets take the same action as the original rule (skipto 1000 and be diverted through NAT for processing)? keep-alive packets are marked with M_SKIP_FIREWALL in netinet/ip_fw2.c::send_pkt You could try to remove that, rebuild and see if it helps. I'm not sure what the reasoning behind this setting was and have no idea what implications it has to change it. If it helps your setup we might want to consider a sysctl to change that behavior. if i remember well, the M_SKIP_FIREWALL is because otherwise they would reset the timer for the session as if a reply had come from the other side. i understand that this makes the interaction with nat a bit problematic. On te other hand, i don't have a better solution. Makes sense. What about having the keep-alive packets take the action of the parent rule? I don't know if that is possible but it seems like it would solve the problem. A note should be added to ipfw(8) to document this behavior, as knowing keep-alive skips the firewall would have saved me a lot of headache. Looks like ip_fw2.c comments are the only place that mention this. Thanks, -James cheers luigi [snip] ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Mysterious packets with stateful ipfw+nat
Ok, this has been driving me nuts for a while. I recently noticed that my 5.4-RELEASE firewall was having a problem with packet leakage. I am seeing the occasional packet on the outside interface with an internal src ip. I put a hub between my firewall and cable modem and verified that the packets are indeed on the wire. Now I am in the process of setting up a new 6.1-RELEASE box and the same issue was happening on my test network. So far I don't get it. I must be missing something obvious. At least everything still works in general. The test setup is a clean install of 6.1-RELEASE, using GENERIC with the ipfw.ko and ipdivert.ko modules loaded. After searching around I was basing the configuration off of: http://lists.freebsd.org/mailman/htdig/freebsd-ipfw/2004-June/001182.html The test box has two Ethernet interfaces, renamed to be isp0 and net0. isp0 is using DHCP, and receives the address 10.42.0.220/24. net0 is running a DHCP server, and sits on 192.168.1.1/24. There is one single piece of hardware on net0 which is always assigned 192.168.1.230. The gateway to the actual Internet sits on 10.42.0.254. A pretty simple setup. The internal machine is just constantly connecting to an external web server to generate traffic. I see the same basic type of thing happen for other usage as well on my main network (ssh sessions, https/http sessions, etc). When looking at tcpdump I am occasionally seeing (on isp0): 19:35:27.591761 aa:aa:aa:5b:db:99 bb:bb:bb:1f:33:da, 192.168.1.230.2542 xx.xx.53.84.80: ., cksum 0xfade (correct), 2295591733:2295591733(0) ack 167570634 win 0 If this packet was truly supposed to be going out on the external interface, it should have gone through NAT and show a src ip of 10.42.0.220. To make it more frustrating, even if I enable ifpfw at layer 2, I am unable to capture these rogue packets. If I watch tcpdump on net0 at the same time, I see the following: 19:35:27.591767 aa:aa:aa:5b:db:98 cc:cc:cc:10:04:ce, xx.xx.53.84.80 192.168.1.230.2542: ., cksum 0xfade (correct), 913:913(0) ack 1256 win 0 The only other thing that I have noticed, is that the packets seem to show up on the external interface at about the same time as the dynamic rules expire. The dynamic rule would look like: 192.168.1.230 2542 - xx.xx.53.84 80 Which is pretty much what I would expect. The same setup with a non-stateful ipfw ruleset (using established keyword) doesn't seem to have this problem. Any ideas? configuration follows. natd.conf unregistered_only yes dynamic yes #deny_incoming yes log_denied yes log_ipfw_denied yes (deny_incoming was set, turned it off to see if it helped but it works the same). * ipfw.rules # Test stateful firewall + natd script cmd=/sbin/ipfw add natout=skipto 1000 oif=isp0 iif=net0 inet=192.168.1.0/24 NOROUTE=( 172.16.0.0/12 or 192.168.0.0/16 or \ 0.0.0.0/8 or 169.254.0.0/16 or 192.0.2.0/24 or 224.0.0.0/4 or 240.0.0.0/4 ) # Start with a clean ruleset /sbin/ipfw -q -f flush # Allow all traffic on the loopback and internal network, to keep this simple. $cmd 2 allow all from any to any via lo0 $cmd 5 allow all from any to any in via $iif $cmd 6 allow all from any to any out xmit $iif # Translate incoming traffic here $cmd 200 divert natd ip from any to any in via $oif $cmd 205 check-state # Outbound # Use stateful inspection to allow any connection from the internal network. $cmd 300 $natout tcp from any to any out via $oif setup keep-state $cmd 305 $natout udp from any to any out via $oif keep-state $cmd 310 $natout icmp from any to any out via $oif keep-state # Inbound # Prevent non-routable networks on the external interface. $cmd 400 deny all from $NOROUTE to any in via $oif # Allow incoming DHCP for external network address assignment. $cmd 450 allow udp from any to any 68 in via $oif keep-state # Allow incoming SSH to this machine $cmd 455 allow tcp from any to me 22 in via $oif setup keep-state # Allow incoming ICMP $cmd 460 allow icmp from any to any icmptypes 0,3,11,12 in via $oif $cmd 999 deny log ip from any to any # NAT rule for outgoing traffic. $cmd 1000 divert natd ip from any to any out via $oif $cmd 1005 allow ip from any to any Thanks for any insight, -James ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [6.x patchset] Ipfw nat and libalias modules
On Mon, Jul 03, 2006 at 01:42:36AM +1000, Vini Engel wrote: Paolo Pisati said the following on 15/05/06 08:05: Released a new revision of my libalias+ipfw work as a patchset for 6.x, get it here: http://mercurio.srv.dsi.unimi.it/~pisati/libalias/libalias-6.x.tgz fixed the checksum corruption occurring to redirected/generated traffic to/by a local interface on the nat box. For more info: http://wikitest.freebsd.org/moin.cgi/PaoloPisati Hi guys, I was wondering how stable this is at the moment? I am very keen on using it on my production box(es) but would like to hear someone else's experience first. i know there're people using it on their productions boxes and i didn't hear anyone complaining, so i assume the code is stable. BTW i just started to cleanup my patch for HEAD, but it'll take a bit before i finish everything, so fell free to use the previous patch. bye -- Paolo Piso's first law: nothing works as expected! ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [6.x patchset] Ipfw nat and libalias modules
Paolo Pisati said the following on 15/05/06 08:05: Released a new revision of my libalias+ipfw work as a patchset for 6.x, get it here: http://mercurio.srv.dsi.unimi.it/~pisati/libalias/libalias-6.x.tgz fixed the checksum corruption occurring to redirected/generated traffic to/by a local interface on the nat box. For more info: http://wikitest.freebsd.org/moin.cgi/PaoloPisati Hi guys, I was wondering how stable this is at the moment? I am very keen on using it on my production box(es) but would like to hear someone else's experience first. Thanks, Vini ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw + nat
mufalani wrote: Hi all, I have a webserver runing apache 2.3 under windows 2003, and one BSD 5.4 (gateway). How to redirect requisitions at 80´s port (200.X.X.X:80) to address (192.x.x.x:80) with nat and ipfw? echo redirect_port tcp 192.x.x.x:80 80 /etc/natd.conf See man natd for details and variants like redirect_address. -- -Chuck ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw + nat
Hi all, I have a webserver runing apache 2.3 under windows 2003, and one BSD 5.4 (gateway). How to redirect requisitions at 80´s port (200.X.X.X:80) to address (192.x.x.x:80) with nat and ipfw? Pretty simple if you are using natd. In /etc/rc.conf: ### Firewall Settings ### firewall_enable=YES ipdivert_enable=YES gateway_enable=YES firewall_type=MYOWN natd_enable=YES natd_interface=xl0 (replace with your external interface) natd_flags=-f /etc/rc.natd # In /etc/rc.natd: # # NATD configurationfile that supplies NATD whit parameters # log no use_sockets yes same_ports yes # Ports redirected to the internal network redirect_port tcp 192.168.0.100:22 222 redirect_port tcp 192.168.0.111:80 80 ^ redirecting ^ obvious^ external port ^ type of traffic^ internal port In the /etc/rc.firewall: divert 8668 ip from any to any via xl0 (will be your external interface) This is all there is to it (put in a simple way...) Regards /Erik Att, Rodrigo Mufalani ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw + nat
On Wed, 7 Jun 2006 20:17:07 -0300 mufalani [EMAIL PROTECTED] wrote: Hi all, I have a webserver runing apache 2.3 under windows 2003, and one BSD 5.4 (gateway). How to redirect requisitions at 80´s port (200.X.X.X:80) to address (192.x.x.x:80) with nat and ipfw? Assuming you're running both already, simply adding the following line (with the appropriate IP addresses, of course) to your natd configuration should do the trick: redirect_port tcp 192.x.x.x:80 200.X.X.X:80 Otherwise, I'd recommend reading the FreeBSD Handbook sections on this (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html and http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-natd.html, for instance). Att, Rodrigo Mufalani ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED] This probably belongs on freebsd-questions, by the way... -- Nick Withers email: [EMAIL PROTECTED] Web: http://www.nickwithers.com Mobile: +61 414 397 446 ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
[6.x patchset] Ipfw nat and libalias modules
Released a new revision of my libalias+ipfw work as a patchset for 6.x, get it here: http://mercurio.srv.dsi.unimi.it/~pisati/libalias/libalias-6.x.tgz fixed the checksum corruption occurring to redirected/generated traffic to/by a local interface on the nat box. For more info: http://wikitest.freebsd.org/moin.cgi/PaoloPisati -- Paolo le influenze esterne sono troppe, il mondo reale non e' mica quello fatato dei komunisti :-p - Anonymous Lumbard ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [6.x patchset] Ipfw nat and libalias modules
Patrick Tracanelli wrote: Probably you dont have the latest RELENG_6 code or it is not in sync (say, manually modified). I have ipfw nat running on -RC1 and -RC2, i386 and amd64 and with clean src the patch applies perfectly. Yes, I try again. And I get error again! cd /usr/obj rm ALL cd /usr/src make clean make clean make update (files changed by patch) make update (NONE!!!) Apply You patch. And I get the same error. I install previous patch, and my PC with NAT in-kernel work OK. Can You help me? Thanks! How is your code sync'ed? Which RELENG from which date? Try rm -rf sys/modules/libalias sys/modules/ipfw sys/conf/files/ cvsug -g -L2 -h cvsup.freebsd.org /usr/share/examples/cvsup/stable-supfile cd /usr/src/ cp patch . patch -p3 patch Do a world build. I am considering your code is not in sync with recent RELENG_6. If it is -RC2 try only rm -rfing the mentioned subdirectories and cvsup. BTW I have static IPFIREWALL so I added options LIBALIAS to my kernel conf file Yes, I find the problem. The problem was in two new files alias_dummy.c and alias_mod.c. Becouse this files is new cvsup don't delete them and patch append to old file (and append, and append, ...) (I didn't try cvsup -D options) When I edit (left only one source, insted of many) compile is OK. Now, I think that we have to make some ipfw example code for NAT in-kernel with and without keep-state/chack-state . I start in monday with stateful ipfw. Thanks for help me!!! (Now I have FreeBSD 6.1) ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [6.x patchset] Ipfw nat and libalias modules
Now, I think that we have to make some ipfw example code for NAT
in-kernel with and without keep-state/chack-state .
I start in monday with stateful ipfw.
Thanks for help me!!!
(Now I have FreeBSD 6.1)
I haven't tried with keep-state yes (dont even know if keep-state is
ready to maintain nat state, I think it is not). The box which is
taking me to internet right now at my building is ipfw nat, for wired
and wireless networks. Here are the running rules:
([EMAIL PROTECTED])~# ipfw show | grep nat
2 19812654104938057 nat 20 ip from { 10.69.69.0/24 or
172.16.69.0/24 } to any out via sis0
20100 27128929 37927915720 nat 20 ip from any to any in via sis0
([EMAIL PROTECTED])~# ipfw nat 20 show config
ipfw nat 20 config if sis0 log unreg_only redir_port tcp
10.69.69.13:4662 4662 redir_port tcp 10.69.69.39:80 3980 redir_port tcp
10.69.69.39:6969 3969
([EMAIL PROTECTED])~# grep nat /etc/rc.firewall
$fwcmd nat 20 config if sis0 log unreg_only redir_port tcp
10.69.69.13:4662 4662 redir_port tcp 10.69.69.39:80 3980 redir_port tcp
10.69.69.39:6969 3969
$fwcmd add 2 set 20 nat 20 all from $redes to any out via $ife
$fwcmd add 20100 set 20 nat 20 all from any to any in via $ife
I have some more enviroments running NAT in in different IPs with
prob, for testing purposes. I can print configs next week, since I
cant access those boxes on weekends.
I hope it helps as example, I have just rewriten selective divert
which I used before into nat rules.
BTW (offside note): Next week I will add a TinyBSD image with ipfw nat
(FreeBSD 6.1) on www.tinybsd.org, so if anyone want to try ipfw nat in
their soekris/wrap/whatever boards, hang on untill wednesday.
--
Patrick Tracanelli
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [6.x patchset] Ipfw nat and libalias modules
Paolo Pisati wrote: I just released a new revision of my libalias+ipfw work as a patchset for 6.x, get it here: http://mercurio.srv.dsi.unimi.it/~pisati/libalias/libalias-6.x.tgz To apply it: cp libalias_ipfw.patch /usr/src cd /usr/src patch -p3 libalias_ipfw.patch then you have to recompile install: kernel, sbin/ipfw, sbin/natd, sbin/ppp, lib/libalias, sys/modules/ipfw, sys/modules/libalias or simply do a world. When I do: cd /usr/src make update (2006-05-05) make clean ... and cp libalias_ipfw.patch /usr/src cd /usr/src patch -p3 libalias_ipfw.patch and make kernel I get the error as follows: ... stage 3.1: making dependencies ... === libalias (depend) === libalias/kld-cuseeme (depend) /usr/src/sys/modules/libalias/kld-cuseeme/../../../conf/kmod.mk, line 177: warning: duplicate script for target alias_cuse /usr/src/sys/modules/libalias/kld-cuseeme/../../../conf/kmod.mk, line 182: warning: duplicate script for target alias_cuse /usr/src/sys/modules/libalias/kld-cuseeme/../../../conf/kmod.mk, line 198: warning: duplicate script for target alias_cuse /usr/src/sys/modules/libalias/kld-cuseeme/../../../conf/kmod.mk, line 202: warning: duplicate script for target alias_cuse /usr/src/sys/modules/libalias/kld-cuseeme/../../../conf/kmod.mk, line 209: warning: duplicate script for target alias_cuse /usr/src/sys/modules/libalias/kld-cuseeme/../../../conf/kmod.mk, line 254: warning: duplicate script for target @ ignored /usr/src/sys/modules/libalias/kld-cuseeme/../../../conf/kmod.mk, line 254: warning: duplicate script for target machine i /usr/src/sys/modules/libalias/kld-cuseeme/../../../conf/kmod.mk, line 446: warning: duplicate script for target lint igno @ - /usr/src/sys machine - /usr/src/sys/i386/include rm -f .depend mkdep -f .depend -a -nostdinc -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -D_KERNEL -DKLD_MODULE -I- -I- cc1: error: -I- specified twice mkdep: compile failed *** Error code 1 Stop in /usr/src/sys/modules/libalias/kld-cuseeme. *** Error code 1 Stop in /usr/src/sys/modules/libalias. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 . Also whel I do make buildworld I get: ... stage 4.2: building libraries ... === lib/libalias (all) === lib/libalias/lib-cuseeme (all) /usr/src/share/mk/bsd.lib.mk, line 110: warning: duplicate script for target libalias_cuseeme.a ignored /usr/src/share/mk/bsd.lib.mk, line 111: warning: duplicate script for target libalias_cuseeme.a ignored /usr/src/share/mk/bsd.lib.mk, line 112: warning: duplicate script for target libalias_cuseeme.a ignored /usr/src/share/mk/bsd.lib.mk, line 113: warning: duplicate script for target libalias_cuseeme.a ignored /usr/src/share/mk/bsd.lib.mk, line 138: warning: duplicate script for target libalias_cuseeme.so.4 ignored /usr/src/share/mk/bsd.lib.mk, line 139: warning: duplicate script for target libalias_cuseeme.so.4 ignored /usr/src/share/mk/bsd.lib.mk, line 141: warning: duplicate script for target libalias_cuseeme.so.4 ignored /usr/src/share/mk/bsd.lib.mk, line 145: warning: duplicate script for target libalias_cuseeme.so.4 ignored /usr/src/share/mk/bsd.lib.mk, line 181: warning: duplicate script for target _EXTRADEPEND ignored cc -O2 -fno-strict-aliasing -pipe -march=pentium-mmx -Werror -Werror -c /usr/src/lib/libalias/lib-cuseeme/../../../sys/neti net/libalias/alias_cuseeme.c building static alias_cuseeme library ranlib libalias_cuseeme.a cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -march=pentium-mmx -Werror -Werror -c /usr/src/lib/libalias/lib-cuseeme/../.. /../sys/netinet/libalias/alias_cuseeme.c -o alias_cuseeme.So building shared library libalias_cuseeme.so.4 === lib/libalias/lib-dummy (all) /usr/src/share/mk/bsd.lib.mk, line 110: warning: duplicate script for target libalias_dummy.a ignored /usr/src/share/mk/bsd.lib.mk, line 111: warning: duplicate script for target libalias_dummy.a ignored /usr/src/share/mk/bsd.lib.mk, line 112: warning: duplicate script for target libalias_dummy.a ignored /usr/src/share/mk/bsd.lib.mk, line 113: warning: duplicate script for target libalias_dummy.a ignored /usr/src/share/mk/bsd.lib.mk, line 138: warning: duplicate script for target libalias_dummy.so.4 ignored /usr/src/share/mk/bsd.lib.mk, line 139: warning: duplicate script for target libalias_dummy.so.4 ignored /usr/src/share/mk/bsd.lib.mk, line 141: warning: duplicate script for target libalias_dummy.so.4 ignored /usr/src/share/mk/bsd.lib.mk, line 145: warning: duplicate script for target libalias_dummy.so.4 ignored /usr/src/share/mk/bsd.lib.mk, line 181: warning: duplicate script for target _EXTRADEPEND ignored cc -O2 -fno-strict-aliasing -pipe -march=pentium-mmx -Werror -Werror -c /usr/src/lib/libalias/lib-dummy/../../../sys/netine t/libalias/alias_dummy.c /usr/src/lib/libalias/lib-dummy/../../../sys/netinet/libalias/alias_dummy.c:235:
Re: [6.x patchset] Ipfw nat and libalias modules
Nenad Gavrilovic wrote: Paolo Pisati wrote: I just released a new revision of my libalias+ipfw work as a patchset for 6.x, get it here: http://mercurio.srv.dsi.unimi.it/~pisati/libalias/libalias-6.x.tgz To apply it: cp libalias_ipfw.patch /usr/src cd /usr/src patch -p3 libalias_ipfw.patch then you have to recompile install: kernel, sbin/ipfw, sbin/natd, sbin/ppp, lib/libalias, sys/modules/ipfw, sys/modules/libalias or simply do a world. When I do: cd /usr/src make update (2006-05-05) make clean ... and cp libalias_ipfw.patch /usr/src cd /usr/src patch -p3 libalias_ipfw.patch strange... is your src tree clean? cd /usrc/src find . -name *.rej lets's see if some patch didn't apply. P. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [6.x patchset] Ipfw nat and libalias modules
Nenad Gavrilovic wrote: Paolo Pisati wrote: I just released a new revision of my libalias+ipfw work as a patchset for 6.x, get it here: http://mercurio.srv.dsi.unimi.it/~pisati/libalias/libalias-6.x.tgz To apply it: cp libalias_ipfw.patch /usr/src cd /usr/src patch -p3 libalias_ipfw.patch then you have to recompile install: kernel, sbin/ipfw, sbin/natd, sbin/ppp, lib/libalias, sys/modules/ipfw, sys/modules/libalias or simply do a world. When I do: cd /usr/src make update (2006-05-05) make clean ... and cp libalias_ipfw.patch /usr/src cd /usr/src patch -p3 libalias_ipfw.patch and make kernel I get the error as follows: Probably you dont have the latest RELENG_6 code or it is not in sync (say, manually modified). I have ipfw nat running on -RC1 and -RC2, i386 and amd64 and with clean src the patch applies perfectly. -- Patrick Tracanelli FreeBSD Brasil LTDA. (31) 3281-9633 / 3281-3547 [EMAIL PROTECTED] http://www.freebsdbrasil.com.br Long live Hanin Elias, Kim Deal! ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [6.x patchset] Ipfw nat and libalias modules
Paolo Pisati wrote: Nenad Gavrilovic wrote: Paolo Pisati wrote: I just released a new revision of my libalias+ipfw work as a patchset for 6.x, get it here: http://mercurio.srv.dsi.unimi.it/~pisati/libalias/libalias-6.x.tgz To apply it: cp libalias_ipfw.patch /usr/src cd /usr/src patch -p3 libalias_ipfw.patch then you have to recompile install: kernel, sbin/ipfw, sbin/natd, sbin/ppp, lib/libalias, sys/modules/ipfw, sys/modules/libalias or simply do a world. When I do: cd /usr/src make update (2006-05-05) make clean ... and cp libalias_ipfw.patch /usr/src cd /usr/src patch -p3 libalias_ipfw.patch strange... is your src tree clean? YES!!! When I get error in first time I do: cd /usr/obj rm ALL cd /usr/src make clean make clean make update and apply You patch. Again I get same error. cd /usrc/src find . -name *.rej NONE!!! lets's see if some patch didn't apply. P. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
[6.x patchset] Ipfw nat and libalias modules
I just released a new revision of my libalias+ipfw work as a patchset for 6.x, get it here: http://mercurio.srv.dsi.unimi.it/~pisati/libalias/libalias-6.x.tgz To apply it: cp libalias_ipfw.patch /usr/src cd /usr/src patch -p3 libalias_ipfw.patch then you have to recompile install: kernel, sbin/ipfw, sbin/natd, sbin/ppp, lib/libalias, sys/modules/ipfw, sys/modules/libalias or simply do a world. With this patch you get: -ipfw nat + redirect + LSNAT support -libalias modules (both in user and kernel land) -for kernel land, all the libalias modules are installed in /boot/kernel as alias_*.ko. -for user land (natd ppp), modules are shared lib loaded according to /etc/libalias.conf. To reload modules for a known process, just 'kill -HUP $PID' it. -natd ppp are patched to use libalias modules If your natd/ppp/ipfw behaves strangely after you applied my patch (i.e. active ftp stops working), remember to check libalias modules. Some ipfw examples: ipfw add nat 666 all from any to any via $IF ipfw nat 666 confg ip 192.168.0.1 # nat with a fixed address ipfw nat 666 confg if $IF log # dynamic if addr nat and logging ipfw nat 666 confg if $IF redir_port ...# redirect support with ipfw nat 666 confg if $IF redir_addr ...# linkspec natd syntax, ipfw nat 666 confg if $IF redir_proto ... # LSNAT works too. # different ipfw rules can be redirected to use # the same nat instance ipfw add nat 666 all from $IP1 to any via $IF1 ipfw add nat 666 all from any to any via $IF2 out ipfw add nat 666 all from $IP2 to $IP3 ipfw nat show # see logs ipfw nat show config# nat configuration To load/unload a libalias module (kernel): kldload alias_ftp # active ftp work ok now kldunload alias_ftp To load/unload a libalias module (user): [edit /etc/libalias.conf and add/cut needed modules] kill -HUP $PID For more info see the readme inside the archive. TODO: Not tested on SMP !i386, logging ability should be improved(right now it's the same as original libalias), documentation should be man-pagified, patchset for 7.x, etcetc bye -- Paolo le influenze esterne sono troppe, il mondo reale non e' mica quello fatato dei komunisti :-p - Anonymous Lumbard ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
