Re: DNAT in freebsd
I think I was misunderstood... Here is the situation i want to handle: My box is a router that handles several /24 behind. One of my links (em0) is connected to a private network 192.168.0.1 is me, my neighbour is 192.168.0.2. I want to make that any connection comes to 192.168.0.1 to go to ip 193.xxx.yyy.2 using specific public ip 84.xx.yy.1 And packets comming to my public 84.xx.yy.1 ip to be trsnslated as came from 192.168.0.1 and sent to 192.168.0.2/or ant other ips behind(192.168.1.xx/24). Hope that makes it clearer, and I appreciate any help. Sami בתאריך 29 ביונ 2013 03:30, מאת "Paul A. Procacci" : > > Hi, (sorry for sending again, the last email was with wrong subject) > > I would like to perform a full dnat/snat as in iptbles in: > > linux-ip.net/html/nat-dnat.html > > How it can be done in fbsd, I use ipfw. > > > > I seeked natd man page but its translation, and thr proxy_rule is for > > specefic port, not a whole transparancy. > > > > Using in-kernel nat is probably a better choice IMHO. > > read `man ipfw(8)` > > The section labeled EXAMPLES has exactly what you need. > Here is a snippet from the manpage to get you started: > > --- > > > Then to configure nat instance 123 to alias all the outgoing traffic with > ip 192.168.0.123, blocking all incoming connections, trying to keep same > ports on both sides, clearing aliasing table on address change and keep- > ing a log of traffic/link statistics: > > ipfw nat 123 config ip 192.168.0.123 log deny_in reset same_ports > > > >ipfw nat 123 config redirect_addr 10.0.0.1 10.0.0.66 >redirect_port tcp 192.168.0.1:80 500 >redirect_proto udp 192.168.1.43 192.168.1.1 >redirect_addr 192.168.0.10,192.168.0.11 >10.0.0.100 # LSNAT >redirect_port tcp 192.168.0.1:80, > 192.168.0.10:22 >500# LSNAT > > > --- > > > ~Paul > > > > This message may contain confidential or privileged information. If you > are not the intended recipient, please advise us immediately and delete > this message. See http://www.datapipe.com/legal/email_disclaimer/ for > further information on confidentiality and the risks of non-secure > electronic communication. If you cannot access these links, please notify > us by reply message and we will send the contents to you. > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Making net.inet6.ip6.v6only=0 default
On Fri, Jun 28, 2013, at 20:15, JINMEI Tatuya / 神明達哉 wrote: > At Fri, 28 Jun 2013 17:30:21 -0500, > "Mark Felder" wrote: > > > Later after a bit more digging and discussion I've come to learn that the > > So, you've gone through the literature on this topic including > http://tools.ietf.org/html/draft-cmetz-v6ops-v4mapped-api-harmful-01 > ? > I had not seen that yet. Thanks for all the feedback you've provided -- you've made some excellent points. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Making net.inet6.ip6.v6only=0 default
At Fri, 28 Jun 2013 17:30:21 -0500, "Mark Felder" wrote: > Later after a bit more digging and discussion I've come to learn that the So, you've gone through the literature on this topic including http://tools.ietf.org/html/draft-cmetz-v6ops-v4mapped-api-harmful-01 ? > security aspect may simply be "unexpected behavior -- the binding to ipv6 > sockets and endusers not realizing it, thus creating a security hole for > environments with only an ipv4 firewall". > > We ship a dual stack firewall by default, and now since FreeBSD 9 we have > the rc.conf setting ipv6_activate_all_interfaces="YES" which seems > sufficient to mitigate this; the user would have to know they're enabling > ipv6 and what its consequences could be. I'm afraid it's a bit too optimistic. We also need to rely on either application programmers being careful enough to write code like this: - sin6 = (struct sockaddr_in6 *) sa; - inet_ntop( AF_INET6, (void *) sin6->sin6_addr.s6_addr, addr, sizeof - addr ); - /* If it's an IPv4 mapped address, drop the leading ':::' */ - if ( IN6_IS_ADDR_V4MAPPED( &(sin6->sin6_addr) ) ) -strncpy( wrapper_addr, addr + 7, sizeof wrapper_addr ); - /* otherwise surround the address with braces to hopefully match - what tcp wrapper expects */ - else sprintf( wrapper_addr, "%s", addr ); -} (taken from the FreeBSD port patch for rwhois) so a naive user can safely write a rule like deny 192.0.2.1 allow all or the user is careful enough to write ACLs like: deny 192.0.2.1 deny :::192.0.2.1 allow all In theory, people (either or both of programmers and users) can make it safe. In practice, I personally think it's sufficiently error prone. Admittedly, however, different people may have difference senses on the severity of this point. And (in my understanding) that's why relevant people failed to get a clear consensus at the time they discussed this API. In the end the "standard" default behavior was documented with leaving lots of controversy. Unfortunately, this also left portability problems. It's not only for FreeBSD; as far as I know NetBSD still keeps the same default as FreeBSD, and, as far as I know OpenBSD still even refuses to allow this usage of IPv4-mapped IPv6 addresses. And, I suspect some of them do so "religiously", and will never change the behavior no matter what the "standard" documentations state. So... > So I guess the question is: what do we do? It looks like we're in > violation of both RFC 3493, Section 5.3 and POSIX 2008, Volume 2, Section > 2.10.20*. ...aside from what FreeBSD should do for ip6.v6only, I personally believe that realistically this issue should be resolved at the application side, i.e., explicitly set the IPV6_V6ONLY socket option to 1 and use both AF_INET (for IPv4) and AF_INET6 (for IPv6, and only for IPv6) sockets. As far as I know this is the most portable behavior. Regarding the rwhois case, I'd first suggest updating the patch with this socket option setting. Hopefully it can be accepted by the upstream because it's most portable. If they still reject it because "it's against the standard" (and even if it's less portable in reality), my next suggestion is to explicitly set the IPV6_V6ONLY socket option to 0. This setting is "redundant" in the sense of standard purity, but hopefully less controversial for those preferring the standard compliance as it only requires a small change and will make it still more portable. Going back to the question of what FreeBSD should do for ip6.v6only: Personally, I'd still suggest keeping the same default because I agree this behavior is sufficiently safer (as noted above) *and* there'll be portability issues anyway (OSes using the different default "religiously" will never change it). But I also understand the argument that standard compliance is more important than debatable safety. In either case, it would help if we provide detailed discussion for the description of this sysctl knob. --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: DNAT in freebsd
> Hi, (sorry for sending again, the last email was with wrong subject) > I would like to perform a full dnat/snat as in iptbles in: > linux-ip.net/html/nat-dnat.html > How it can be done in fbsd, I use ipfw. > > I seeked natd man page but its translation, and thr proxy_rule is for > specefic port, not a whole transparancy. > Using in-kernel nat is probably a better choice IMHO. read `man ipfw(8)` The section labeled EXAMPLES has exactly what you need. Here is a snippet from the manpage to get you started: --- Then to configure nat instance 123 to alias all the outgoing traffic with ip 192.168.0.123, blocking all incoming connections, trying to keep same ports on both sides, clearing aliasing table on address change and keep- ing a log of traffic/link statistics: ipfw nat 123 config ip 192.168.0.123 log deny_in reset same_ports ipfw nat 123 config redirect_addr 10.0.0.1 10.0.0.66 redirect_port tcp 192.168.0.1:80 500 redirect_proto udp 192.168.1.43 192.168.1.1 redirect_addr 192.168.0.10,192.168.0.11 10.0.0.100 # LSNAT redirect_port tcp 192.168.0.1:80,192.168.0.10:22 500# LSNAT --- ~Paul This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/legal/email_disclaimer/ for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Making net.inet6.ip6.v6only=0 default
After a brief talk on IRC I figured I'd get some feelers out there about this sysctl which seems to have a long history. Background: I recently updated the net/rwhoisd port here on FreeBSD with a patch from the kind hrs@ who fixed it so it binds on both ipv4 AND ipv6 when it is built with ipv6 (default since last summer in the ports tree). I sent the patch upstream, and I received feedback from a list user that the real problem is FreeBSD's lack of compliance and we really should change net.inet6.ip6.v6only=0 to fix it. Now, originally I was just going to add an install message with the port to change that sysctl, but I was told it is dangerous and I wasn't sure of the consequences. I'm quite familiar with ipv6 networking, but not specifically this setting and its consequences among software out there and I didn't want unknown behavior on my production servers. The patch hrs@ sent me seemed a better solution at the time. Later after a bit more digging and discussion I've come to learn that the security aspect may simply be "unexpected behavior -- the binding to ipv6 sockets and endusers not realizing it, thus creating a security hole for environments with only an ipv4 firewall". We ship a dual stack firewall by default, and now since FreeBSD 9 we have the rc.conf setting ipv6_activate_all_interfaces="YES" which seems sufficient to mitigate this; the user would have to know they're enabling ipv6 and what its consequences could be. So I guess the question is: what do we do? It looks like we're in violation of both RFC 3493, Section 5.3 and POSIX 2008, Volume 2, Section 2.10.20*. *I read the RFC, but haven't looked up the POSIX spec yet. Both were listed in a forum post from 2010. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
DNAT in freebsd
Hi, (sorry for sending again, the last email was with wrong subject) I would like to perform a full dnat/snat as in iptbles in: linux-ip.net/html/nat-dnat.html How it can be done in fbsd, I use ipfw. I seeked natd man page but its translation, and thr proxy_rule is for specefic port, not a whole transparancy. Thanks in advance, -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly
The following reply was made to PR kern/179901; it has been noted by GNATS. From: Mark Linimon To: bug-follo...@freebsd.org Cc: Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly Date: Fri, 28 Jun 2013 14:56:07 -0500 - Forwarded message from Bernd Walter - Date: Fri, 28 Jun 2013 20:58:52 +0200 From: Bernd Walter To: lini...@freebsd.org Cc: freebsd-net@freebsd.org, freebsd-b...@freebsd.org Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly User-Agent: Mutt/1.5.11 It is unrelated, but I have found the cause for it and filed kern/180065 together with a working patch. The reason is that the packets have no valid checksums when processed in ip6_input because of delayed checksum changes. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. - End forwarded message - ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly
The following reply was made to PR kern/179901; it has been noted by GNATS. From: Mark Linimon To: bug-follo...@freebsd.org Cc: Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly Date: Fri, 28 Jun 2013 14:55:38 -0500 - Forwarded message from Bernd Walter - Date: Fri, 28 Jun 2013 12:15:14 +0200 From: Bernd Walter To: lini...@freebsd.org Cc: freebsd-b...@freebsd.org, freebsd-net@freebsd.org Subject: Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly User-Agent: Mutt/1.5.11 I don't know if this is related or a different bug, but the same mentioned commits are suspicious for us. We had been running with our own IPv6 software into the same REUSEADDR problem and changed to REUSEPORT as this is how it is done in mcastread from mcast-tools port. Don't know where we originally got the REUSEADDR from, probably a Stevens book. So far binding works with this change in our software. However we only receive packets from network and not packets from the host itself. We use multicast to notify multiple processes on multiple machines, including the machine itself. To reproduce: - use two hosts - start mcastread on each of them on an interface with shared LAN - send via mcastsend on one host - packets are received on the other host, but not with the mcastread on the same host -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. - End forwarded message - ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/180065: [netinet6] [patch] Multicast loopback to own host broken
Old Synopsis: Multicast loopback to own host broken New Synopsis: [netinet6] [patch] Multicast loopback to own host broken Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jun 28 19:59:39 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=180065 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly
On Fri, Jun 28, 2013 at 12:15:14PM +0200, Bernd Walter wrote: > On Mon, Jun 24, 2013 at 03:59:24AM +, lini...@freebsd.org wrote: > > Old Synopsis: [patch] Multicast SO_REUSEADDR handled incorrectly > > New Synopsis: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly > > > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > > Responsible-Changed-By: linimon > > Responsible-Changed-When: Mon Jun 24 03:59:05 UTC 2013 > > Responsible-Changed-Why: > > Over to maintainer(s). > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=179901 > > ___ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > > I don't know if this is related or a different bug, but the same > mentioned commits are suspicious for us. > We had been running with our own IPv6 software into the same REUSEADDR > problem and changed to REUSEPORT as this is how it is done in mcastread > from mcast-tools port. > Don't know where we originally got the REUSEADDR from, probably a Stevens > book. > So far binding works with this change in our software. > However we only receive packets from network and not packets from > the host itself. > We use multicast to notify multiple processes on multiple machines, > including the machine itself. > To reproduce: > - use two hosts > - start mcastread on each of them on an interface with shared LAN > - send via mcastsend on one host > - packets are received on the other host, but not with the mcastread >on the same host It is unrelated, but I have found the cause for it and filed kern/180065 together with a working patch. The reason is that the packets have no valid checksums when processed in ip6_input because of delayed checksum changes. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Dnay
Hi, I would like to perform a full dnat/snat as in iptbles in: linux-ip.net/html/nat-dnat.html How it can be done in fbsd, I use ipgw. Thanks in advance, Sami ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: misc/179033: [dc] dc ethernet driver seems to have issues with some multiport card and mother board combinations
On Wednesday, June 26, 2013 12:37:13 am Mr. Clif wrote: > Hi John, > > Thanks for working on this. I'm very interested in getting this fixed > for everyone that uses the Affected Atom boards and other small format > boards that work well in small custom routers. > > However right now I have a big network upgrade I'm working on and don't > have time to get to it until late July, I'm hoping. So please forgive me > for the long delay. That is fine. I've been able to test this on a little netbook I have that has bridges with the ISA enable bit set and have fixed a few bugs. The updated patch is at the URL below. I wasn't able to test your specific use case yet however (of the BIOS using an invalid range). > Thanks for your help, > Clif > > > John Baldwin wrote: > > On Monday, June 10, 2013 3:13:11 pm Mr. Clif wrote: > >> Hi John and Pyun, > >> > >> Ok got the new kernel installed and tested. Yes it works! :-) Maybe that > >> will also fix a simular problem with the sun cards (cas[03]), except I > >> don't see a define like that in if_cas.c. Suggestions? > > So I have a possible "real" fix for this. However, I do not have any > > hardware > > I can find that has a PCI-PCI bridge with the ISA-enable bit set. I know it > > compiles and boots fine on other systems. Can you please try this and > > capture > > the dmesg output? It would also be good to capture devinfo -u output before > > and after. > > > > http://www.freebsd.org/~jhb/patches/pci_isa_enable.patch > > > > -- John Baldwin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/179901: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly
On Mon, Jun 24, 2013 at 03:59:24AM +, lini...@freebsd.org wrote: > Old Synopsis: [patch] Multicast SO_REUSEADDR handled incorrectly > New Synopsis: [netinet] [patch] Multicast SO_REUSEADDR handled incorrectly > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Mon Jun 24 03:59:05 UTC 2013 > Responsible-Changed-Why: > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=179901 > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" I don't know if this is related or a different bug, but the same mentioned commits are suspicious for us. We had been running with our own IPv6 software into the same REUSEADDR problem and changed to REUSEPORT as this is how it is done in mcastread from mcast-tools port. Don't know where we originally got the REUSEADDR from, probably a Stevens book. So far binding works with this change in our software. However we only receive packets from network and not packets from the host itself. We use multicast to notify multiple processes on multiple machines, including the machine itself. To reproduce: - use two hosts - start mcastread on each of them on an interface with shared LAN - send via mcastsend on one host - packets are received on the other host, but not with the mcastread on the same host -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
