Re: natd port forward times out, tcpdump yields nothing
Kage wrote:
Well, no, see it's hitting natd just fine as shown by my natd verbose
logs, if you're assuming ipfw is blocking me from reaching natd. Are
you talking about adding a firewall rule for each of my round-robin
addresses, too?
Yes
How would that do any good?
All response paquet to a paquet diverted to natd must also be diverted
to natd to be reverse translated. eg:
incoming request from client (c) to server (s) redirected to server (S)
c.c.c.c -> s.s.s.s nated as c.c.c.c -> S.S.S.S
must have response paquetd reverse translated:
S.S.S.S -> c.c.c.c nated as s.s.s.s -> c.c.c.c
to be a valid response to client (c).
On Sat, Mar 22, 2008 at 9:27 AM, Henri Hennebert <[EMAIL PROTECTED]> wrote:
Kage wrote:
> Hey guys,
>
>This is a fun one that's stumped people in Freenode ##freebsd.
> Basically, I have this layout:
>
> irc.domain.com -> DNS A -> IRC Jail
>
> When someone connects to irc.domain.com on IRC ports (6667, 8067,
> etc.), it round-robins them using natd, otherwise it sends all other
> port requests to the IRC jail as per normal (such as port 80, which is
> my primary concern). As for having it setup to have ipfw divert to
> natd, that's done and works, as shown by natd verbose mode:
>
> In {default}[TCP] [TCP] 72.65.73.23:2980 -> 207.210.114.45:6667 aliased to
>[TCP] 72.65.73.23:2980 -> 207.210.114.45:6667
>
> (For reference)
> 207.210.114.45 = jail IP
> 72.20.28.202 = example target IP in the round-robin
> 72.65.73.23 = my IP
>
> Right now, my ipfw.rules file is as follows:
>
> [EMAIL PROTECTED] /etc]# cat ipfw.rules
> IPF="ipfw -q add"
> ipfw -f -q flush
>
> #loopback
> $IPF 10 allow all from any to any via lo0
> $IPF 20 deny all from any to 127.0.0.0/8
> $IPF 30 deny all from 127.0.0.0/8 to any
> $IPF 40 deny tcp from any to any frag
>
> # statefull
> $IPF 50 check-state
> $IPF 60 allow tcp from any to any established
> $IPF 70 allow all from any to any out keep-state
> $IPF 54999 allow icmp from any to any
>
> # Include the deny file
> . /etc/ipfw.deny
>
> [snip -- some allowed ports]
> # IRC (natd divert for IRC port-forwarding
> $IPF 50220 divert natd all from any to 207.210.114.45 6667 via rl0
> $IPF 50230 divert natd all from any to 207.210.114.45 8067 via rl0
> $IPF 50240 divert natd all from any to 207.210.114.45 8068 via rl0
> $IPF 50250 divert natd all from any to 207.210.114.45 6697 via rl0
> $IPF 50260 divert natd all from any to 207.210.114.45 7000 via rl0
You must also divert the response trafic AFAIK eg:
$IPF 50220 divert natd all from 72.20.28.202 6667 to 207.210.114.45 via rl0
> # keep these two IRC ports normally open for BNC
> $IPF 50270 allow all from any to any 31337 in
> $IPF 50380 allow all from any to any 31337 out
> [snip -- more allowed ports]
> # deny and log everything
> $IPF 55000 deny log all from any to any
>
> -
>
> Here's a dump of ipfw show, with some stuff cut out for space purposes
> (they're just denied DDoS IPs)
>
> [EMAIL PROTECTED] /etc]# ipfw show
> 00010 61124 16056802 allow ip from any to any via lo0
> 00020 0 0 deny ip from any to 127.0.0.0/8
> 00030 0 0 deny ip from 127.0.0.0/8 to any
> 00040 0 0 deny tcp from any to any frag
> 00050 0 0 check-state
> 00060 670616 455926379 allow tcp from any to any established
> 00070 16213 14071853 allow ip from any to any out keep-state
> [snip]
> 50220468 22464 divert 8668 ip from any to 207.210.114.45
> dst-port 6667 via rl0
> 50230 0 0 divert 8668 ip from any to 207.210.114.45
> dst-port 8067 via rl0
> 50240 0 0 divert 8668 ip from any to 207.210.114.45
> dst-port 8068 via rl0
> 50250 0 0 divert 8668 ip from any to 207.210.114.45
> dst-port 6697 via rl0
> 50260 0 0 divert 8668 ip from any to 207.210.114.45
> dst-port 7000 via rl0
> 50270 160 allow ip from any to any dst-port 31337 in
> 54999 66 3991 allow icmp from any to any
> 55000 4364343609 deny log logamount 100 ip from any to any
> 65535 29 4176 allow ip from any to any
>
> My natd.conf is as follows:
>
> [EMAIL PROTECTED] /etc]# cat natd.conf
> # Nub.Core NATd
> verbose
> alias_address 207.210.114.45
> log
> log_denied
> log_ipfw_denied
> pid_file /var/run/natd.pid
>
>
> ### IRC Redirect Ports
> # 6667
If I understand man natd
redirect_port tcp 72.20.28.202:6667 207.210.114.45:6667 207.210.114.45:6667
^
Trafic is comming from 72.65.73.23 - so the rule don't apply
[EMAIL PROTECTED] /etc]#
>
> And, as stated above, I am showing connection diverts to natd. When I
> run the following three tcpdumps:
>
> tcpdump -s 0 -w me_to_nat.pcap -vvv -i rl0 src host 72.65.73.23 and
> dst host 207.210.114.45 and dst port 6667
> tcpdump -s 0 -w nat_to_jail.pcap -vvv -i rl0 src host 72
Re: kern/122033: [ral] Lock order reversal in ral0 at bootup (regression)
Synopsis: [ral] Lock order reversal in ral0 at bootup (regression) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Mon Mar 24 11:01:07 UTC 2008 Responsible-Changed-Why: Send to -net team, this is a nic. http://www.freebsd.org/cgi/query-pr.cgi?pr=122033 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Current problem reports assigned to freebsd-net@FreeBSD.org
Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description o kern/35442 net[sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 netchanging interface ipaddress doesn't seem to work s kern/39937 netipstealth issue s kern/81147 net[net] [patch] em0 reinitialization while adding aliase s kern/86920 net[ndis] ifconfig: SIOCS80211: Invalid argument (regress o kern/92090 net[bge] bge0: watchdog timeout -- resetting f kern/92552 netA serious bug in most network drivers from 5.X to 6.X o kern/95288 net[pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr s kern/105943 netNetwork stack may modify read-only mbuf chain copies o kern/106316 net[dummynet] dummynet with multipass ipfw drops packets o kern/108542 net[bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/112528 net[nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net[patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net[udp] IP v4 udp fragmented packet reject o kern/113842 net[ipv6] PF_INET6 proto domain state can't be cleared wi o kern/114714 net[gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net[fxp] fxp looses ability to speak with traffic o kern/115239 net[ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net[ip] [patch] 6.2-STABLE panic during use of multi-cast f kern/116172 net[tun] [panic] Network / ipv6 recursive mutex panic o kern/116185 net[iwi] if_iwi driver leads system to reboot o kern/116328 net[bge]: Solid hang with bge interface o kern/116747 net[ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net[tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net[em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net[tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net[vlan] Duplicate IP on different interfaces o kern/117448 net[carp] 6.2 kernel crash (regression) o kern/118880 net[ipv6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net[wi] 7.0-RC1 no carrier with Prism 2.5 wifi card (regr o kern/119345 net[ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net[bge] bge(4) transmit performance problem o kern/119945 net[rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net[carp] [panic] carp causes kernel panics in any conste o kern/120266 net[panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net[netgraph] [patch] netgraph source assumes 32-bit time f kern/120725 net[bce] On board second lan port 'bce1' with Broadcom Ne f kern/120966 net[rum]: kernel panic with if_rum and WPA encryption o kern/121181 net[panic] Fatal trap 3: breakpoint instruction fault whi o kern/121437 net[vlan] Routing to layer-2 address does not work on VLA o kern/121555 netFatal trap 12: current process = 12 (swi1: net) o kern/121624 net[em] [regression] Intel em WOL fails after upgrade to o kern/121872 net[wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net[fxp] fxp0 MBUF and PAE o kern/122033 net[ral] Lock order reversal in ral0 at bootup (regressio 45 problems total. Non-critical problems S Tracker Resp. Description o conf/23063 net[PATCH] for static ARP tables in rc.network s bin/41647netifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net[nfs] [patch] NFS root configurations without dynamic s kern/60293 netFreeBSD arp poison patch o kern/64556 net[sis] if_sis short cable fix problems with NetGear FA3 o kern/77913 net[wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o bin/79228net[patch] extend /sbin/arp to be able to create blackhol o kern/93378 net[tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 netpacket drops periodically appear o kern/95277 net[netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net[netisr] suggestion to fix suboptimal network polling o kern/102035 net[plip] plip networking disables parallel port printing o conf/102502 net[patch] ifconfig name does't rename netgraph node in n o conf/107035 net[patch] bridge interface given in rc.conf not taking a o kern/109470 net[wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/112179 net[sis] [patch] sis driver for natsemi DP8
Re: IPsec AH tunneling pakcet mis-handling?
On Wed, 1 Aug 2007, blue wrote:
Hi,
Dear all:
I do not know the purpose of the following codes in the very beginning in
ip6_input():
#ifdef IPSEC
/*
* should the inner packet be considered authentic?
* see comment in ah4_input().
*/
if (m) {
m->m_flags &= ~M_AUTHIPHDR;
m->m_flags &= ~M_AUTHIPDGM;
}
#endif
Consider the case: a packet is encrypted as AH tunneled, and FreeBSD is the
end point of the tunnel. After it tore off the outer IPv6 header, the mbuf
will be inserted to NETISR again. Then ip6_forward() will be called again to
process the packet. However, in ipsec6_in_reject(), the packet's source and
destination will match the SP entry. Since ip6_input() has truned off the
flag M_AUTHIPHDR and M_AUTHIPDGM, the packet will be dropped.
I don't think with the codes AH tunnel could work properly.
I was pointed at this.
I am a bit unsure about your setup as you are talking about "AH
tunneled" and "encrypted" while at the end it's "AH tunnel" only.
So, are you using IPsec tunnel mode with ESP and AH or just AH, or ...?
Can you describe the setup this would be a problem in detail and maybe
file a PR so this won't be lost again.
We've got other ESP+AH+IPv6 problems pending like PR kern/121373 and I
could look into both at the same time I guess.
PS: I am assuming this was with (Fast) IPsec, not KAME IPsec
implementation? The date was too close to the change, so I thought it
might be better asking;-)
Thanks
/bz
--
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
Software is harder than hardware so better get it right the first time.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPsec AH tunneling pakcet mis-handling?
Sorry, maybe my words make you confused.
What I meant is "AH tunnel" only, and the code base is FAST_IPSEC, which
is currently IPSEC in FreeBSD-7.0.
BR,
Yi-Wen
Bjoern A. Zeeb wrote:
On Wed, 1 Aug 2007, blue wrote:
Hi,
Dear all:
I do not know the purpose of the following codes in the very
beginning in ip6_input():
#ifdef IPSEC
/*
* should the inner packet be considered authentic?
* see comment in ah4_input().
*/
if (m) {
m->m_flags &= ~M_AUTHIPHDR;
m->m_flags &= ~M_AUTHIPDGM;
}
#endif
Consider the case: a packet is encrypted as AH tunneled, and FreeBSD
is the end point of the tunnel. After it tore off the outer IPv6
header, the mbuf will be inserted to NETISR again. Then ip6_forward()
will be called again to process the packet. However, in
ipsec6_in_reject(), the packet's source and destination will match
the SP entry. Since ip6_input() has truned off the flag M_AUTHIPHDR
and M_AUTHIPDGM, the packet will be dropped.
I don't think with the codes AH tunnel could work properly.
I was pointed at this.
I am a bit unsure about your setup as you are talking about "AH
tunneled" and "encrypted" while at the end it's "AH tunnel" only.
So, are you using IPsec tunnel mode with ESP and AH or just AH, or ...?
Can you describe the setup this would be a problem in detail and maybe
file a PR so this won't be lost again.
We've got other ESP+AH+IPv6 problems pending like PR kern/121373 and I
could look into both at the same time I guess.
PS: I am assuming this was with (Fast) IPsec, not KAME IPsec
implementation? The date was too close to the change, so I thought it
might be better asking;-)
Thanks
/bz
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: zerocopy bpf commits impending
On Mon, 24 Mar 2008, Christian S.J. Peron wrote: I just want everyone to know that I have completed the zerocopy bpf commit. Please be on the "lookout" for any strange bpf related issues. For people that want to test the new zerocopy bpf implementation, a patch can be found here: http://people.freebsd.org/~csjp/pcap.1206364304.diff Any comments, patches etc can be sent to Robert Watson (rwatson@) or myself. FYI, right now there is a known issue in which only one of the two BPF buffers can be owned by user processes at a time. As a result, when acking one buffer, it's almost always the case that userspace will enter select() even though another buffer is essentially ready, leading to a system call being generated for each buffer even though that's undesirable. I'm working on some changing allowing both buffers to be owned by userspace at a time, but it will be a couple of weeks before that enters CVS. I believe that the current libpcap patches should keep working with that fine, although of course, we'll see. :-) The bpf.4 documentation is very careful to warn that applications should not assume that there are any invariants about the number of buffers assigned to userspace at a time. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: zerocopy bpf commits impending
I just want everyone to know that I have completed the zerocopy bpf commit. Please be on the "lookout" for any strange bpf related issues. For people that want to test the new zerocopy bpf implementation, a patch can be found here: http://people.freebsd.org/~csjp/pcap.1206364304.diff Any comments, patches etc can be sent to Robert Watson (rwatson@) or myself. Thanks! ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: zerocopy bpf commits impending
Pardon the basic question, but is the current patchset "zero copy" or "one copy"? The paper I saw a link to described a mechanism to eliminate one of the two copies the traditional bpf approach makes but I haven't taken a look into the actual code. Pete ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: zerocopy bpf commits impending
On Mon, 24 Mar 2008, Petri Helenius wrote: Pardon the basic question, but is the current patchset "zero copy" or "one copy"? The paper I saw a link to described a mechanism to eliminate one of the two copies the traditional bpf approach makes but I haven't taken a look into the actual code. The short answer is "one-copy". This eliminates the copy between the kernel and user space, but not the possibility of in-kernel copying. In practice, that in-kernel copying is frequently desirable as: (1) It allows packing of headers into a buffer when a small snaplen is used, which greatly reduces memory overhead when capturing, for example, just TCP headers and not payloads. (2) It allows us to more easily maintain independence between separate BPF sessions, and in particular, to avoid leaking memory between kernel, userspace, and different BPF consumers. If doing full capture of all packet data to userspace, the approach we took would improve performance, but would still involve one full copy of packet data in kernel. Further work would be required to eliminate that copy. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: natd port forward times out, tcpdump yields nothing
Still not working, but I DO have natd aliasing properly. Here's my
natd output (remember which IP is mine, the IRC jail, and the example
round-robin IP):
[EMAIL PROTECTED] /etc]# natd -f /etc/natd.conf
In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased to
[TCP] 72.65.73.23:2897 -> 72.20.28.202:6667
In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased to
[TCP] 72.65.73.23:2897 -> 72.20.28.202:6667
In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased to
[TCP] 72.65.73.23:2897 -> 72.20.28.202:6667
72...23 (me) is hitting the natd on the jail IP (207...45), which is
getting correctly aliased to 72...202 (example round-robin IP). So it
appears the natd is working properly. Here's my natd configuration as
it exists now:
# Nub.Core NATd
verbose
alias_address 207.210.114.45
log
log_denied
log_ipfw_denied
pid_file /var/run/natd.pid
### IRC Redirect Ports
# 6667
redirect_port tcp 72.20.28.202:6667 207.210.114.45:6667
And for more record, here's my ipfw.rules file up until the divert:
[EMAIL PROTECTED] /etc]# cat ipfw.rules
IPF="ipfw -q add"
ipfw -f -q flush
#loopback
$IPF 10 allow all from any to any via lo0
$IPF 20 deny all from any to 127.0.0.0/8
$IPF 30 deny all from 127.0.0.0/8 to any
$IPF 40 deny tcp from any to any frag
# statefull
$IPF 50 check-state
$IPF 60 allow tcp from any to any established
$IPF 70 allow all from any to any out keep-state
$IPF 54999 allow icmp from any to any
[snip -- Some allowed ports (port 80, 443, etc.), and some denied IPs]
# IRC (natd divert for IRC port-forwarding
$IPF 50220 divert natd all from 72.20.28.202 6667 to 207.210.114.45 6667 via rl0
$IPF 50221 divert natd all from any to 207.210.114.45 6667 via rl0
Any attempt to connect to the IRC jail IP thus far, though, still
fails with a "connection timed out."
Thanks for your help thus far. Any additional ideas?
On Mon, Mar 24, 2008 at 6:10 AM, Henri Hennebert <[EMAIL PROTECTED]> wrote:
> Kage wrote:
> > Well, no, see it's hitting natd just fine as shown by my natd verbose
> > logs, if you're assuming ipfw is blocking me from reaching natd. Are
> > you talking about adding a firewall rule for each of my round-robin
> > addresses, too?
>
> Yes
>
>
> > How would that do any good?
>
> All response paquet to a paquet diverted to natd must also be diverted
> to natd to be reverse translated. eg:
>
> incoming request from client (c) to server (s) redirected to server (S)
>
> c.c.c.c -> s.s.s.s nated as c.c.c.c -> S.S.S.S
>
> must have response paquetd reverse translated:
>
> S.S.S.S -> c.c.c.c nated as s.s.s.s -> c.c.c.c
>
> to be a valid response to client (c).
>
>
>
> >
> > On Sat, Mar 22, 2008 at 9:27 AM, Henri Hennebert <[EMAIL PROTECTED]> wrote:
> >> Kage wrote:
> >> > Hey guys,
> >> >
> >> >This is a fun one that's stumped people in Freenode ##freebsd.
> >> > Basically, I have this layout:
> >> >
> >> > irc.domain.com -> DNS A -> IRC Jail
> >> >
> >> > When someone connects to irc.domain.com on IRC ports (6667, 8067,
> >> > etc.), it round-robins them using natd, otherwise it sends all other
> >> > port requests to the IRC jail as per normal (such as port 80, which is
> >> > my primary concern). As for having it setup to have ipfw divert to
> >> > natd, that's done and works, as shown by natd verbose mode:
> >> >
> >> > In {default}[TCP] [TCP] 72.65.73.23:2980 -> 207.210.114.45:6667
> aliased to
> >> >[TCP] 72.65.73.23:2980 -> 207.210.114.45:6667
> >> >
> >> > (For reference)
> >> > 207.210.114.45 = jail IP
> >> > 72.20.28.202 = example target IP in the round-robin
> >> > 72.65.73.23 = my IP
> >> >
> >> > Right now, my ipfw.rules file is as follows:
> >> >
> >> > [EMAIL PROTECTED] /etc]# cat ipfw.rules
> >> > IPF="ipfw -q add"
> >> > ipfw -f -q flush
> >> >
> >> > #loopback
> >> > $IPF 10 allow all from any to any via lo0
> >> > $IPF 20 deny all from any to 127.0.0.0/8
> >> > $IPF 30 deny all from 127.0.0.0/8 to any
> >> > $IPF 40 deny tcp from any to any frag
> >> >
> >> > # statefull
> >> > $IPF 50 check-state
> >> > $IPF 60 allow tcp from any to any established
> >> > $IPF 70 allow all from any to any out keep-state
> >> > $IPF 54999 allow icmp from any to any
> >> >
> >> > # Include the deny file
> >> > . /etc/ipfw.deny
> >> >
> >> > [snip -- some allowed ports]
> >> > # IRC (natd divert for IRC port-forwarding
> >> > $IPF 50220 divert natd all from any to 207.210.114.45 6667 via rl0
> >> > $IPF 50230 divert natd all from any to 207.210.114.45 8067 via rl0
> >> > $IPF 50240 divert natd all from any to 207.210.114.45 8068 via rl0
> >> > $IPF 50250 divert natd all from any to 207.210.114.45 6697 via rl0
> >> > $IPF 50260 divert natd all from any to 207.210.114.45 7000 via rl0
> >>
> >>
> >> You must also divert the response trafic AFAIK eg:
> >>
> >> $IPF 50220 divert natd
Re: "established" on { tcp or udp } rules
On Thu, Mar 20, 2008 at 2:03 AM, Vadim Goncharov <[EMAIL PROTECTED]> wrote:
> This is behaviour of ipfw2 - options are independently ANDed. Thus, man page
> explicitly says:
>
> established
> Matches TCP packets that have the RST or ACK bits set.
>
> So, it is obvious that udp packet will not match and thus entire rule will
> not
> match.
Yeah, it's just weird that it lets you write a rule that will never match.
I'll have to fire up FreeBSD 4.11 (and possibly earlier with just
ipfw1) in a VM and check things there. I'm sure back in the 4.x days
that ipfw would error out if you wrote a UDP rule with TCP options at
the end, as that is what got me in the habit of writing separate UDP
and TCP rules.
Now that I found the { udp or tcp } syntax, I was rewriting some rules
on a test firewall and noticed that it would accept TCP option even if
udp was listed.
--
Freddie Cash
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPsec AH tunneling pakcet mis-handling?
On Mon, 24 Mar 2008, blue wrote:
Hi,
Sorry, maybe my words make you confused.
What I meant is "AH tunnel" only, and the code base is FAST_IPSEC, which is
currently IPSEC in FreeBSD-7.0.
thanks for the clarification. Can you open a PR with all this
information so a) it woon't be lost and b) you'll get feedback.
Get it assigned to bz@
Thanks
BR,
Yi-Wen
Bjoern A. Zeeb wrote:
On Wed, 1 Aug 2007, blue wrote:
Hi,
Dear all:
I do not know the purpose of the following codes in the very beginning in
ip6_input():
#ifdef IPSEC
/*
* should the inner packet be considered authentic?
* see comment in ah4_input().
*/
if (m) {
m->m_flags &= ~M_AUTHIPHDR;
m->m_flags &= ~M_AUTHIPDGM;
}
#endif
Consider the case: a packet is encrypted as AH tunneled, and FreeBSD is
the end point of the tunnel. After it tore off the outer IPv6 header, the
mbuf will be inserted to NETISR again. Then ip6_forward() will be called
again to process the packet. However, in ipsec6_in_reject(), the packet's
source and destination will match the SP entry. Since ip6_input() has
truned off the flag M_AUTHIPHDR and M_AUTHIPDGM, the packet will be
dropped.
I don't think with the codes AH tunnel could work properly.
I was pointed at this.
I am a bit unsure about your setup as you are talking about "AH
tunneled" and "encrypted" while at the end it's "AH tunnel" only.
So, are you using IPsec tunnel mode with ESP and AH or just AH, or ...?
Can you describe the setup this would be a problem in detail and maybe
file a PR so this won't be lost again.
We've got other ESP+AH+IPv6 problems pending like PR kern/121373 and I
could look into both at the same time I guess.
PS: I am assuming this was with (Fast) IPsec, not KAME IPsec
implementation? The date was too close to the change, so I thought it
might be better asking;-)
Thanks
/bz
--
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
Software is harder than hardware so better get it right the first time.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/116077: 6.2-STABLE panic during use of multi-cast networking client
The following reply was made to PR kern/116077; it has been noted by GNATS. From: Norbert Papke <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: kern/116077: 6.2-STABLE panic during use of multi-cast networking client Date: Mon, 24 Mar 2008 10:29:51 -0700 I have applied the commit and retested by 1) restarting multi-cast clients and 2) rebooting the system. I have not been able to reproduce the failure. The commit fixes the problem for me. Thanks! -- Norbert Papke. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: route-to not working
Stephan,
I tried to use your example, but the packet is replying to wrong
interface Do you think that it's a bug?
Best regards,
Wesley
On Thu, Mar 20, 2008 at 9:57 AM, Stefan Lambrev <
[EMAIL PROTECTED]> wrote:
> Greetings,
>
>
> Wesley wrote:
> > Dear people,
> >
> > I have 2 links on a box, and I don't want to load balance it but, only
> to
> > reply requests in the same interface that it comes.
> >
> > I tried to use the route-to, but it not seems to work.
> >
> > Could you please, give-me a help?
> >
> I do not see where you use "reply-to" in you configuration
>
> But here is working example which you can improve off course.
>
> #dual home
> pass in on $ext_if1 reply-to ($ext_if1 $gw1) from any to $external_addr1
> keep state
> pass out on $ext_if2 route-to ($ext_if1 $gw1) from $external_addr1 to any
> pass in on $ext_if2 reply-to ($ext_if2 $gw2) from any to $external_addr2
> keep state
> pass out on $ext_if1 route-to ($ext_if2 $gw1) from $external_addr2 to any
>
> #dual home ssh only
> pass out on $ext_if2 route-to ($ext_if1 $gw1) from $external_addr1 to any
> pass out on $ext_if1 route-to ($ext_if2 $gw1) from $external_addr2 to any
> pass in on $ext_if1 reply-to ($ext_if1 $gw1) proto tcp from any to
> $external_addr1 port 22 keep state
> pass in on $ext_if2 reply-to ($ext_if2 $gw2) proto tcp from any to
> $external_addr2 port 22 keep state
> > It's my configuration:
> >
> > set skip on lo0
> > scrub on xl0 reassemble tcp no-df random-id
> > scrub on xl1 reassemble tcp no-df random-id
> > scrub on dc0 reassemble tcp no-df random-id
> > nat on xl0 from 172.16.0.0/24 to any -> (xl0) static-port
> > rdr on dc0 inet proto tcp to port 80 -> 127.0.0.1 port 3128 round-robin
> > sticky-address
> > antispoof quick for {xl0,dc0,xl1}
> > block proto tcp from 172.16.0.0/24 to any port 3128
> > # Internal Traffic
> > pass in quick on dc0 from any to any
> > pass out quick on dc0 from any to any
> > # Outgoing
> > pass out on xl0 proto tcp all flags S/SA modulate state
> > pass out on xl0 proto { udp, icmp } all keep state
> > pass out on xl1 proto tcp all flags S/SA modulate state
> > pass out on xl1 proto { udp, icmp } all keep state
> > # Pass basic services
> > pass in quick on xl1 proto tcp from any to any port { 22, 21, 1194 }
> keep
> > state
> > pass in quick on xl0 proto tcp from any to any port { 22, 21, 1194 }
> keep
> > state
> > pass in on xl0 proto udp from any to any port 53
> > pass in on xl1 proto udp from any to any port 53
> > # Pass VPN
> > pass in quick on xl1 proto udp from any to port 1194 keep state
> > pass quick on tun0
> > # Source nat route
> > pass out log on xl0 route-to ( xl1 200.232.164.1 ) from xl1 to any
> > pass out on xl1 route-to ( xl0 201.83.16.1 ) from xl0 to any
> > # Close
> > block return-rst in log quick on xl0 inet proto tcp from any to any
> > block return-rst in log quick on xl1 inet proto tcp from any to any
> > block return-icmp in log quick on xl0 proto udp from any to any
> > block return-icmp in log quick on xl1 proto udp from any to any
> > block in quick on xl0 all
> > block in quick on xl1 all
> >
> > Best Regards,
> >
> > Wesley Gentine
> > ___
> > freebsd-net@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> >
>
> --
>
> Best Wishes,
> Stefan Lambrev
> ICQ# 24134177
>
>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lock order reversal in ral driver
Robert Jenssen wrote: Hi, Since upgrading to FreeBSD 7 I have been experiencing some frustrating problems with my RAL wifi card. In particular, it seems to me that dhclient fails when the ral device driver times out while scanning for my access point. At the same time my HP PDA with Spectec WiFi SDIO card has no problems finding my access point. Today I made a kernel with the following options: makeoptions DEBUG=-g options INVARIANTS options INVARIANT_SUPPORT options WITNESS options DEBUG_LOCKS options DEBUG_VFS_LOCKS options DIAGNOSTIC options SOCKBUF_DEBUG options DDB options KDB Upon rebooting the dmesg immediately showed a lock order reversal in the ral driver in ieee80211_scan.c and rt2560.c (see below). Does this correspond to my symptoms? Is there a wizard out there who understands what is happening? <...stuff snipped...> The LOR is unrelated to any issues you are seeing and can be safely ignored. Try providing a description of your setup and a log that indicates the problem. For the latter look at wlandebug(8). Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: natd port forward times out, tcpdump yields nothing
Kage wrote:
Still not working, but I DO have natd aliasing properly. Here's my
natd output (remember which IP is mine, the IRC jail, and the example
round-robin IP):
[EMAIL PROTECTED] /etc]# natd -f /etc/natd.conf
In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased to
[TCP] 72.65.73.23:2897 -> 72.20.28.202:6667
In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased to
[TCP] 72.65.73.23:2897 -> 72.20.28.202:6667
In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased to
[TCP] 72.65.73.23:2897 -> 72.20.28.202:6667
72...23 (me) is hitting the natd on the jail IP (207...45), which is
getting correctly aliased to 72...202 (example round-robin IP). So it
appears the natd is working properly.
In the client -> server direction only for now -- see bellow.
Here's my natd configuration as
it exists now:
# Nub.Core NATd
verbose
alias_address 207.210.114.45
log
log_denied
log_ipfw_denied
pid_file /var/run/natd.pid
### IRC Redirect Ports
# 6667
redirect_port tcp 72.20.28.202:6667 207.210.114.45:6667
And for more record, here's my ipfw.rules file up until the divert:
[EMAIL PROTECTED] /etc]# cat ipfw.rules
IPF="ipfw -q add"
ipfw -f -q flush
#loopback
$IPF 10 allow all from any to any via lo0
$IPF 20 deny all from any to 127.0.0.0/8
$IPF 30 deny all from 127.0.0.0/8 to any
$IPF 40 deny tcp from any to any frag
# statefull
$IPF 50 check-state
$IPF 60 allow tcp from any to any established
$IPF 70 allow all from any to any out keep-state
$IPF 54999 allow icmp from any to any
[snip -- Some allowed ports (port 80, 443, etc.), and some denied IPs]
# IRC (natd divert for IRC port-forwarding
$IPF 50220 divert natd all from 72.20.28.202 6667 to 207.210.114.45 6667 via rl0
The destination port must not be given (ie any destination port
corresponding to any source port greater than 1023 for the request) - in
this test the source port is 2897, in the next one it may be anything >
1023. Moreover `any' in place of 207.210.114.45 would be nice to allow
others to chat. So the rule should be:
$IPF 50220 divert natd all from 72.20.28.202 6667 to any via rl0
Henri
$IPF 50221 divert natd all from any to 207.210.114.45 6667 via rl0
Any attempt to connect to the IRC jail IP thus far, though, still
fails with a "connection timed out."
Thanks for your help thus far. Any additional ideas?
On Mon, Mar 24, 2008 at 6:10 AM, Henri Hennebert <[EMAIL PROTECTED]> wrote:
Kage wrote:
> Well, no, see it's hitting natd just fine as shown by my natd verbose
> logs, if you're assuming ipfw is blocking me from reaching natd. Are
> you talking about adding a firewall rule for each of my round-robin
> addresses, too?
Yes
> How would that do any good?
All response paquet to a paquet diverted to natd must also be diverted
to natd to be reverse translated. eg:
incoming request from client (c) to server (s) redirected to server (S)
c.c.c.c -> s.s.s.s nated as c.c.c.c -> S.S.S.S
must have response paquetd reverse translated:
S.S.S.S -> c.c.c.c nated as s.s.s.s -> c.c.c.c
to be a valid response to client (c).
>
> On Sat, Mar 22, 2008 at 9:27 AM, Henri Hennebert <[EMAIL PROTECTED]> wrote:
>> Kage wrote:
>> > Hey guys,
>> >
>> >This is a fun one that's stumped people in Freenode ##freebsd.
>> > Basically, I have this layout:
>> >
>> > irc.domain.com -> DNS A -> IRC Jail
>> >
>> > When someone connects to irc.domain.com on IRC ports (6667, 8067,
>> > etc.), it round-robins them using natd, otherwise it sends all other
>> > port requests to the IRC jail as per normal (such as port 80, which is
>> > my primary concern). As for having it setup to have ipfw divert to
>> > natd, that's done and works, as shown by natd verbose mode:
>> >
>> > In {default}[TCP] [TCP] 72.65.73.23:2980 -> 207.210.114.45:6667
aliased to
>> >[TCP] 72.65.73.23:2980 -> 207.210.114.45:6667
>> >
>> > (For reference)
>> > 207.210.114.45 = jail IP
>> > 72.20.28.202 = example target IP in the round-robin
>> > 72.65.73.23 = my IP
>> >
>> > Right now, my ipfw.rules file is as follows:
>> >
>> > [EMAIL PROTECTED] /etc]# cat ipfw.rules
>> > IPF="ipfw -q add"
>> > ipfw -f -q flush
>> >
>> > #loopback
>> > $IPF 10 allow all from any to any via lo0
>> > $IPF 20 deny all from any to 127.0.0.0/8
>> > $IPF 30 deny all from 127.0.0.0/8 to any
>> > $IPF 40 deny tcp from any to any frag
>> >
>> > # statefull
>> > $IPF 50 check-state
>> > $IPF 60 allow tcp from any to any established
>> > $IPF 70 allow all from any to any out keep-state
>> > $IPF 54999 allow icmp from any to any
>> >
>> > # Include the deny file
>> > . /etc/ipfw.deny
>> >
>> > [snip -- some allowed ports]
>> > # IRC (natd divert for IRC port-forwarding
>> > $IPF 50220 divert natd all from any to 207.210.114.45 6667 v
Re: natd port forward times out, tcpdump yields nothing
I changed my rules, and it's still not working:
$IPF 50220 divert natd all from 72.20.28.202 6667 to any via rl0
$IPF 50221 divert natd all from any to 207.210.114.45 6667 via rl0
It's still timing connections out.
On Mon, Mar 24, 2008 at 4:24 PM, Henri Hennebert <[EMAIL PROTECTED]> wrote:
> Kage wrote:
> > Still not working, but I DO have natd aliasing properly. Here's my
> > natd output (remember which IP is mine, the IRC jail, and the example
> > round-robin IP):
> >
> > [EMAIL PROTECTED] /etc]# natd -f /etc/natd.conf
> > In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased
> to
> >[TCP] 72.65.73.23:2897 -> 72.20.28.202:6667
> > In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased
> to
> >[TCP] 72.65.73.23:2897 -> 72.20.28.202:6667
> > In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased
> to
> >[TCP] 72.65.73.23:2897 -> 72.20.28.202:6667
> >
> > 72...23 (me) is hitting the natd on the jail IP (207...45), which is
> > getting correctly aliased to 72...202 (example round-robin IP). So it
> > appears the natd is working properly.
>
> In the client -> server direction only for now -- see bellow.
>
>
>
> > Here's my natd configuration as
> > it exists now:
> >
> > # Nub.Core NATd
> > verbose
> > alias_address 207.210.114.45
> > log
> > log_denied
> > log_ipfw_denied
> > pid_file /var/run/natd.pid
> >
> > ### IRC Redirect Ports
> > # 6667
> > redirect_port tcp 72.20.28.202:6667 207.210.114.45:6667
> >
> > And for more record, here's my ipfw.rules file up until the divert:
> >
> > [EMAIL PROTECTED] /etc]# cat ipfw.rules
> > IPF="ipfw -q add"
> > ipfw -f -q flush
> >
> > #loopback
> > $IPF 10 allow all from any to any via lo0
> > $IPF 20 deny all from any to 127.0.0.0/8
> > $IPF 30 deny all from 127.0.0.0/8 to any
> > $IPF 40 deny tcp from any to any frag
> >
> > # statefull
> > $IPF 50 check-state
> > $IPF 60 allow tcp from any to any established
> > $IPF 70 allow all from any to any out keep-state
> > $IPF 54999 allow icmp from any to any
> >
> > [snip -- Some allowed ports (port 80, 443, etc.), and some denied IPs]
> >
> > # IRC (natd divert for IRC port-forwarding
> > $IPF 50220 divert natd all from 72.20.28.202 6667 to 207.210.114.45 6667
> via rl0
>
> The destination port must not be given (ie any destination port
> corresponding to any source port greater than 1023 for the request) - in
> this test the source port is 2897, in the next one it may be anything >
> 1023. Moreover `any' in place of 207.210.114.45 would be nice to allow
> others to chat. So the rule should be:
>
> $IPF 50220 divert natd all from 72.20.28.202 6667 to any via rl0
>
> Henri
>
>
>
> > $IPF 50221 divert natd all from any to 207.210.114.45 6667 via rl0
> >
> > Any attempt to connect to the IRC jail IP thus far, though, still
> > fails with a "connection timed out."
> >
> > Thanks for your help thus far. Any additional ideas?
> >
> > On Mon, Mar 24, 2008 at 6:10 AM, Henri Hennebert <[EMAIL PROTECTED]> wrote:
> >> Kage wrote:
> >> > Well, no, see it's hitting natd just fine as shown by my natd verbose
> >> > logs, if you're assuming ipfw is blocking me from reaching natd. Are
> >> > you talking about adding a firewall rule for each of my round-robin
> >> > addresses, too?
> >>
> >> Yes
> >>
> >>
> >> > How would that do any good?
> >>
> >> All response paquet to a paquet diverted to natd must also be diverted
> >> to natd to be reverse translated. eg:
> >>
> >> incoming request from client (c) to server (s) redirected to server (S)
> >>
> >> c.c.c.c -> s.s.s.s nated as c.c.c.c -> S.S.S.S
> >>
> >> must have response paquetd reverse translated:
> >>
> >> S.S.S.S -> c.c.c.c nated as s.s.s.s -> c.c.c.c
> >>
> >> to be a valid response to client (c).
> >>
> >>
> >>
> >> >
> >> > On Sat, Mar 22, 2008 at 9:27 AM, Henri Hennebert <[EMAIL PROTECTED]>
> wrote:
> >> >> Kage wrote:
> >> >> > Hey guys,
> >> >> >
> >> >> >This is a fun one that's stumped people in Freenode ##freebsd.
> >> >> > Basically, I have this layout:
> >> >> >
> >> >> > irc.domain.com -> DNS A -> IRC Jail
> >> >> >
> >> >> > When someone connects to irc.domain.com on IRC ports (6667, 8067,
> >> >> > etc.), it round-robins them using natd, otherwise it sends all
> other
> >> >> > port requests to the IRC jail as per normal (such as port 80,
> which is
> >> >> > my primary concern). As for having it setup to have ipfw divert to
> >> >> > natd, that's done and works, as shown by natd verbose mode:
> >> >> >
> >> >> > In {default}[TCP] [TCP] 72.65.73.23:2980 -> 207.210.114.45:6667
> aliased to
> >> >> >[TCP] 72.65.73.23:2980 -> 207.210.114.45:6667
> >> >> >
> >> >> > (For reference)
> >> >> > 207.210.114.
Re: kern/122058: [em] [panic] Panic on em1: taskq
Old Synopsis: Panic on em1: taskq New Synopsis: [em] [panic] Panic on em1: taskq Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Mar 25 06:16:30 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=122058 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
