Redirecting traffic with IPSec and pf doesn't work
Hello, What I'm trying to accomplish is the following: - there are two machines, connected over the internet (let's call them A and B) - when A tries to connect to B:port, or B to A:port (via TCP, port is just a TCP port, in this case, 3306) the connection should be redirected to a local listener, instead of the remote - the above should only be done if I want to (I can do this with pf anchors or tables) - the connection between the two machines should be secured in kernel space (for efficiency and performance) I can redirect the connections in the unsecured (no IPSec) case with the following pf.conf (this is for machine A): rdr proto tcp from any to B_IP port 3306 -> 192.168.254.1 port 3306 pass out log on $ext_if route-to (lo0 127.0.0.1 ) proto tcp from any to B_IP port 3306 (192.168.254.1 is an alias on A's lo0) So when I do a telnet from A to B, the connection establishes and I can reach A's listener, instead of B's. Now with IPSec. ipsec.conf contains this (along with the PSK definitions): spdadd A_IP B_IP any -P out ipsec esp/transport/A_IP-B_IP/default ah/transport/A_IP-B_IP/default; and the same on B, with swapped orders. IPSec between the two machines works, but the redirection doesn't. pf.conf now has: rdr pass log proto tcp from any to B_IP port 3306 -> 192.168.254.1 port 3306 pass out log on enc0 route-to (lo0 127.0.0.1 ) proto tcp from any to B_IP port 3306 (192.168.254.1 is lo0's alias address in this case, but I've also tried with A's public IP and also with a gif tunnel) What I see in pflog's output seems to be OK: 100. 062276 rule 6/0(match): pass out on enc0: A_IP.59940 > B_IP.3306: S 3107058076:3107058076(0) win 65535 3,sackOK,timestamp 69415267 0> 38 rule 0/0(match): rdr in on lo0: A_IP.59940 > 192.168.254.1.3306: S 3107058076:3107058076(0) win 65535 3,sackOK,timestamp 69415267 0> and the traffic shows up on enc0 as well, but is not that nice: 11:57:36.482910 (confidential): SPI 0x3d55: IP A_IP.59940 > B_IP.3306: S 3107058076:3107058076(0) win 65535 3,sackOK,timestamp 69415267 0> 11:57:36.483009 (confidential): SPI 0x3d55: IP A_IP.59940 > B_IP.3306: R 3107058077:3107058077(0) win 0 The command, which produced the above output is: MACHINE_A $ telnet B_IP 3306 telnet: connect to address B_IP: Interrupted system call telnet: Unable to connect to remote host I've tried to set net.enc.out.ipsec_filter_mask to different values without success, only 0x0 gave a connection refused answer, instead of "Interrupted system call". This is on 7-STABLE. Is redirecting TCP flows on IPSec secured connections impossible because some layering differences? (maybe the above redirects the packet with IPSec headers, so this causes the problem) Thanks, ___ 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: Redirecting traffic with IPSec and pf doesn't work
Attila Nagy wrote: Hello, What I'm trying to accomplish is the following: - there are two machines, connected over the internet (let's call them A and B) - when A tries to connect to B:port, or B to A:port (via TCP, port is just a TCP port, in this case, 3306) the connection should be redirected to a local listener, instead of the remote - the above should only be done if I want to (I can do this with pf anchors or tables) - the connection between the two machines should be secured in kernel space (for efficiency and performance) I can redirect the connections in the unsecured (no IPSec) case with the following pf.conf (this is for machine A): rdr proto tcp from any to B_IP port 3306 -> 192.168.254.1 port 3306 pass out log on $ext_if route-to (lo0 127.0.0.1 ) proto tcp from any to B_IP port 3306 (192.168.254.1 is an alias on A's lo0) So when I do a telnet from A to B, the connection establishes and I can reach A's listener, instead of B's. Now with IPSec. ipsec.conf contains this (along with the PSK definitions): spdadd A_IP B_IP any -P out ipsec esp/transport/A_IP-B_IP/default ah/transport/A_IP-B_IP/default; and the same on B, with swapped orders. IPSec between the two machines works, but the redirection doesn't. pf.conf now has: rdr pass log proto tcp from any to B_IP port 3306 -> 192.168.254.1 port 3306 pass out log on enc0 route-to (lo0 127.0.0.1 ) proto tcp from any to B_IP port 3306 (192.168.254.1 is lo0's alias address in this case, but I've also tried with A's public IP and also with a gif tunnel) What I see in pflog's output seems to be OK: 100. 062276 rule 6/0(match): pass out on enc0: A_IP.59940 > B_IP.3306: S 3107058076:3107058076(0) win 65535 3,sackOK,timestamp 69415267 0> 38 rule 0/0(match): rdr in on lo0: A_IP.59940 > 192.168.254.1.3306: S 3107058076:3107058076(0) win 65535 3,sackOK,timestamp 69415267 0> and the traffic shows up on enc0 as well, but is not that nice: 11:57:36.482910 (confidential): SPI 0x3d55: IP A_IP.59940 > B_IP.3306: S 3107058076:3107058076(0) win 65535 3,sackOK,timestamp 69415267 0> 11:57:36.483009 (confidential): SPI 0x3d55: IP A_IP.59940 > B_IP.3306: R 3107058077:3107058077(0) win 0 The command, which produced the above output is: MACHINE_A $ telnet B_IP 3306 telnet: connect to address B_IP: Interrupted system call telnet: Unable to connect to remote host I've tried to set net.enc.out.ipsec_filter_mask to different values without success, only 0x0 gave a connection refused answer, instead of "Interrupted system call". This is on 7-STABLE. Is redirecting TCP flows on IPSec secured connections impossible because some layering differences? (maybe the above redirects the packet with IPSec headers, so this causes the problem) Thanks, ___ 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 on 7.x but on 6.x you have to turn on optionsIPSEC_FILTERGIF #filter ipsec packets from a tunnel to get packets to go thru ipfilter - I assume it is the same for pf. I had the same problem not being able to redirect packets coming from a ipsec tunnel until I turned this option on. HTH, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) ___ 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: Redirecting traffic with IPSec and pf doesn't work
Stephen Clark wrote: Attila Nagy wrote: Hello, What I'm trying to accomplish is the following: - there are two machines, connected over the internet (let's call them A and B) - when A tries to connect to B:port, or B to A:port (via TCP, port is just a TCP port, in this case, 3306) the connection should be redirected to a local listener, instead of the remote - the above should only be done if I want to (I can do this with pf anchors or tables) - the connection between the two machines should be secured in kernel space (for efficiency and performance) I can redirect the connections in the unsecured (no IPSec) case with the following pf.conf (this is for machine A): rdr proto tcp from any to B_IP port 3306 -> 192.168.254.1 port 3306 pass out log on $ext_if route-to (lo0 127.0.0.1 ) proto tcp from any to B_IP port 3306 (192.168.254.1 is an alias on A's lo0) So when I do a telnet from A to B, the connection establishes and I can reach A's listener, instead of B's. Now with IPSec. ipsec.conf contains this (along with the PSK definitions): spdadd A_IP B_IP any -P out ipsec esp/transport/A_IP-B_IP/default ah/transport/A_IP-B_IP/default; and the same on B, with swapped orders. IPSec between the two machines works, but the redirection doesn't. pf.conf now has: rdr pass log proto tcp from any to B_IP port 3306 -> 192.168.254.1 port 3306 pass out log on enc0 route-to (lo0 127.0.0.1 ) proto tcp from any to B_IP port 3306 (192.168.254.1 is lo0's alias address in this case, but I've also tried with A's public IP and also with a gif tunnel) What I see in pflog's output seems to be OK: 100. 062276 rule 6/0(match): pass out on enc0: A_IP.59940 > B_IP.3306: S 3107058076:3107058076(0) win 65535 3,sackOK,timestamp 69415267 0> 38 rule 0/0(match): rdr in on lo0: A_IP.59940 > 192.168.254.1.3306: S 3107058076:3107058076(0) win 65535 1460,nop,wscale 3,sackOK,timestamp 69415267 0> and the traffic shows up on enc0 as well, but is not that nice: 11:57:36.482910 (confidential): SPI 0x3d55: IP A_IP.59940 > B_IP.3306: S 3107058076:3107058076(0) win 65535 3,sackOK,timestamp 69415267 0> 11:57:36.483009 (confidential): SPI 0x3d55: IP A_IP.59940 > B_IP.3306: R 3107058077:3107058077(0) win 0 The command, which produced the above output is: MACHINE_A $ telnet B_IP 3306 telnet: connect to address B_IP: Interrupted system call telnet: Unable to connect to remote host I've tried to set net.enc.out.ipsec_filter_mask to different values without success, only 0x0 gave a connection refused answer, instead of "Interrupted system call". This is on 7-STABLE. Is redirecting TCP flows on IPSec secured connections impossible because some layering differences? (maybe the above redirects the packet with IPSec headers, so this causes the problem) Thanks, ___ 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 on 7.x but on 6.x you have to turn on optionsIPSEC_FILTERGIF #filter ipsec packets from a tunnel to get packets to go thru ipfilter - I assume it is the same for pf. I had the same problem not being able to redirect packets coming from a ipsec tunnel until I turned this option on. Yes, but I'm sending, not receiving. So I want to redirect on the sender side ___ 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"
HEADS UP: INET dependencies in the kernel
Hi, over the last days I fixed a few places missing #ifdef INET as well changed the kernel build file in sys/conf/files and added depencies for those parts that really require INET to compile / work at the moment. WARNING: This means for example if you build a kernel without INET you will no longer get gre, ipfw, libablias, ipsec, if_enc, if_bridge, nfsserver, .. Those will _silently_ be disabled whether or not they are in your kernel configuration. WARNING: You will also not get any of the 12 interfaces I found that had a compile time dependency on INET (if you remove INET from your kernel config): if_age, if_alc, if_ale, if_em, if_igb, if_fxp, if_ixgbe, if_jme, if_msk, if_mxge, if_sk, if_txp. I will send out an extra mail with more information on each interface and how to fix later in a second. (The same may apply to some other code). See r193824, r193949-193950, 193954, 193956-193957, 193960, 193983, 193986-193988, 193990-193991, 193993-193994, 193996-193997 of sys/conf/files for what was changed and if you are looking for a network project to cleanup a bit of our stack. For now I didn't see much of a problem here, as virtually noone so far would have built a kernel without INET support and still wanted networking as it just hadn't (easily) been possible. Obviously people may be concerned that those things will rot and warn others with #error anymore and that other people will one day trip over this. Unless hit by a bus I do not intend to drop this ball but will work (together with you!) to clean things up, resolve them, etc. For now the goal was to actually see how much of impure code we have and clean things basically up before 8.0. Now do not expect that I caught all and everything. We are far away from that. The long term goal is to separate INET6 off INET. So in addition to a kernel config like: include LINT ident LINT-NOINET6 nooptions INET6 FreeBSD 8 LINT currently also builds a kernel with: include LINT ident LINT-NOINET makeoptions NO_MODULES=yes nooptions INET nooptions INET6 Note: LINT will not boot! In case of arm I include AVILA, in case of mips I used ADM5120 instead of LINT (as arm and mips do not have LINT). HINT FOR DEVELOPERS: For developers this means that if you add new code you really should make sure that INET in addition to INET6 will be properly #ifdefed. KIND OF HEADS UP FOR DEVLEOPERS: This is kind of a heads up that from the time 8 will be branched off and HEAD will be 9 all new code should 1) have feature parity for INET and INET6 where applicable 2) new/changed code that only has #ifdef INET6 but no #ifdef INET (where applicable) should no longer be done. 3) No it's not April 1st today;-) Regards, Bjoern -- Bjoern A. Zeeb The greatest risk is not taking one. ___ 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"
Ethernet NIC drivers depending unconditionally on INET
Hi, as announced in my other mail to current@ and net@ I added the mandatory "INET" dependency to 12 Ethernet NIC drivers. Additionally I am adding if_bridge here as well. Those drivers should be fixed and once done the (mandatory) inet dependency should be removed again from sys/conf/files for that driver. If you have questions, need help, compile testing, ... feel free to mail me. I won't be able to test things as I do not own all of the different cases but I can review patches, .. Generally speaking upfront: if one of the drivers mentioned here or not, supportes offload capabilities for rx or tx of v4 or v6, for tcp, udp, sctp, .. they need to be properly hidden under the apropriate #ifdefs. Everything that needs v4 belongs under #ifdef INET. Everything that needs v6 belongs under #ifdef INET6. Upper layer protocols like TCP, UDP, SCTP should be at least #if defined (INET) || defined(INET6). In case of SCTP probebly #ifdef (SCTP) as well. You will need to include opt_inet.h, opt_inet6.h, opt_sctp.h in those cases and at least the buildkernel (not building the module alone) part should properly check them. For single module builds we are kind of lost here and I think we usually enabled things by default as they are in GENERIC. Another general note that scared me while looking at CSUM_TSO and IFCAP_TSO4|IFCAP_TSO6. Almost none of the drivers actually checks that it is an IPv4 packet before grabiing the IP header, TCP header, ... How do we actually know that it is an IPv4 packet in all those drivers? Should we do a IP Version fiel check? I think em(4) is one of those that does. I hope this will improve with tuexen's work on the CSUM flags. In case you are maintaining another driver but cannot find it on the list - be sure we'll find you during the 9.x lifecycle in case you do not properly handle things;-) if_age: I identifed two in_pseudo() calls that are INET specific. The problem is that thi is part of the (IPv4) TSO code and it seems to be mandatory for that case. The proper fix seems to be to but that block under #ifdef INET and in case INET is not defined to also disable announcing or permitting to set these features entirely as we won't be able to handle them or use them anyway. if_alc: There is one in_pseudo(); Apart from that things seem identical to if_age. if_ale: There is one in_pseudo(); Apart from that things seem identical to if_age. if_em: There is one in_pseudo() in em_tso_setup() that prevented the driver from being linked into the kernel; the entire code unfortunately has at least one more place of IP/IPV6 distinction for cksum offloading em_transmit_checksum_setup() that is not properly handled either. In either case the feature should be disbaled and not be announced if the address family is not there to handle the code. Note: tuexen is working on a proper set of v4/v6 definitions for the csum offloading, so we will be able to do this more fine grained in the future. For now not having INET6 would penalize INET as well. if_igb: igb_tso_setup() has one in_pseudo() call. See if_age for that. It also has dependencies on the entire LRO framework like tcp_lro_free(), tcp_lro_rx(), tcp_lro_flush(), tcp_lro_init(). The LRO framework is on the IPv6TODO list. For the moment if there is no INET LRO should be completely compiled out and not advertised removing the TUNABLE and SYSCTL and changing the default to 0. Be prepared in case LRO will arrive for IPv6. Side note: calling tcp_lro_free() on something that hadn't been initialized for example because lro was enabled by the sysctl after itniialization, can that be a problem? Maybe tcp_lro_free() should just return in case cntl is NULL? if_fxp: There is one in_pseudo(); Apart from that things seem identical to if_age. ixgbe: There is one in_pseudo() in ixgbe_tso_setup(). See if_igb for that. There is an arp_ifinit() call in ixgbe_ioctl() that already seems to check for the proper address family and only needs the #ifdefs around like the ioctl in if_em has. The same that applies for if_igb about LRO applies here as well. if_jme: Two in_pseudo() calls; see if_age. if_msk: An in_cksum_skip() call. Almost like if_age but this seems to be further conditional on driver flags and CSUM_TCP that seem to be set independently of TSO. I am not entirely sure if there is a proper solution or if we might be forced to return an error in that case in case there is not INET support. if_mxge: mxge_rx_csum() has one in_pseudo(). The function and callers already seem to know how do deal with results in case the csum can't
Re: HEADS UP: INET dependencies in the kernel
Bjoern A. Zeeb wrote: This is kind of a heads up that from the time 8 will be branched off and HEAD will be 9 all new code should 1) have feature parity for INET and INET6 where applicable As a sort of side-note, what about feature parity for INET6 for existing IPV4 features like TSO? Who is working on that? Thanks, Drew ___ 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: Ethernet NIC drivers depending unconditionally on INET
On Thu, Jun 11, 2009 at 08:33:28PM +, Bjoern A. Zeeb wrote: > Hi, > > as announced in my other mail to current@ and net@ I added the > mandatory "INET" dependency to 12 Ethernet NIC drivers. Additionally > I am adding if_bridge here as well. > > Those drivers should be fixed and once done the (mandatory) inet > dependency should be removed again from sys/conf/files for that > driver. > > If you have questions, need help, compile testing, ... feel free to > mail me. I won't be able to test things as I do not own all of the > different cases but I can review patches, .. > > > Generally speaking upfront: if one of the drivers mentioned here or > not, supportes offload capabilities for rx or tx of v4 or v6, for tcp, > udp, sctp, .. they need to be properly hidden under the apropriate > #ifdefs. > > Everything that needs v4 belongs under #ifdef INET. > Everything that needs v6 belongs under #ifdef INET6. > Upper layer protocols like TCP, UDP, SCTP should be at least > #if defined (INET) || defined(INET6). > In case of SCTP probebly #ifdef (SCTP) as well. > > You will need to include opt_inet.h, opt_inet6.h, opt_sctp.h > in those cases and at least the buildkernel (not building the module > alone) part should properly check them. For single module builds > we are kind of lost here and I think we usually enabled things by > default as they are in GENERIC. > > Another general note that scared me while looking at CSUM_TSO and > IFCAP_TSO4|IFCAP_TSO6. Almost none of the drivers actually checks > that it is an IPv4 packet before grabiing the IP header, TCP header, > ... How do we actually know that it is an IPv4 packet in all those Yeah, there are no checksum offloading support for IPv6 under FreeBSD so there are no cases the frames are IPv6 when CSUM_IP/CSUM_TCP/CSUM_UDP/CSUM_TSO was set. > drivers? Should we do a IP Version fiel check? I think em(4) is one I believe this should be done in upper stack. Upper stack already know IP version as well as other useful fields(e.g. IP header length, TCP header length, etc). You wouldn't want to parse mbuf chains which takes a lot of CPU cycles. > of those that does. I hope this will improve with tuexen's work on > the CSUM flags. > > In case you are maintaining another driver but cannot find it on the > list - be sure we'll find you during the 9.x lifecycle in case you do > not properly handle things;-) > [ list of drivers part removed ] I guess you missed hme(4) and gem(4) in the list and most old hardwares that supports checksum offloading have no capability to handle IPv6 checksum offloading. If we do not define appropriate capabilities(IFCAP_RXCSUM_IPV4, IFCAP_TXCSUM_IPV6, IFCAP_RXCSUM_TCPV4, IFCAP_TXCSUM_TCPV6 etc) first it would be hard to change code, I guess. ___ 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: panic with ng_ipfw+ng_car and net.inet.ip.fw.one_pass=0
On Fri, 5 Jun 2009 22:56:47 +0400 Oleg Bulyzhin wrote: > On Fri, Jun 05, 2009 at 04:57:52PM +0300, Mikolaj Golub wrote: > >> It works for me. With the patch I has not managed to crash the system using >> my >> test. Some notes: >> >> - only ng_ipfw/ng_car subsystem has been tested (not dummynet). >> - my -current box is under qemu (I don't have real server running -current to >> test this). >> >> If you are interesting in some testing of dummynet before commiting this to >> current, let me know. I could try some tests but only the next week. > > I did some testing of dummynet though extra testing would not hurt. I see the patch has been commited to 8-CURRENT :-). Thanks. I did some dummy tests on "fixed" current (simple dummynet configuration + traffic + ipfw reloaded every second) and did not have any issues. At present I don't have old -current without fix to reproduce the crash, but on 7-STABLE running this test I saw in dmesg many ipfw: ouch!, skip past end of rules, denying packet messages and one time crashed the system. So it looks like my testbase rather good and would have found problems with fixed current if they still had had. -- Mikolaj Golub ___ 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/135222: [igb] low speed routing between two igb interfaces
Synopsis: [igb] low speed routing between two igb interfaces Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jun 12 05:46:45 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=135222 ___ 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"
[ng_car] issue/whish/todo
Good day I would like ещ introduce You several issue. I would like to be able to when you call "_getstat_" to see the bytes, not only packets. This is for drawing graphs of node load. I would also like to be able to configure some "_car_nods_" after exit on output, without checking in ipfw, not depending on ip.fw.one_pass. Like per ng_car node one_pass. is it real? ___ 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: IPv6 Ideas
Nathan Lay (2009-04-24 20:39 +0200):
>> What are your problems with using radvd? I have used it quite a bit
>> on FreeBSD (6.1) without any hassle. It's even written quite nicely
>> in my experience so working on patches for it should be quite
>> do-able if there are features missing.
>>
> radvd actually does support DNS advertisement (but rtsol doesn't, so
> it doesn't matter).
I'm sorry for the late response. I had over 500 unread messages in this
mailing list.
It's true that radvd supports the RDNSS option (RFC 5006). Just add
something like this to your radvd.conf:
interface whatever
{
# *snipp*
RDNSS 2001:16d8::1::1
{
};
};
I have written a client side implementation of RDNSS. It was developed
under FreeBSD, but seems to work under Linux as well. Some early testing
has been done under MacOS X as well.
You can find it here:
http://hack.org/mc/hacks/radns/
It doesn't support aging of the RDNSS data yet and you need some way to
make it play well with a DHCP client if you're running dual stack,
otherwise they will compete for /etc/resolv.conf.
I'm hoping to be able to find the time to clean up radns, add aging and
a script to work with dhclient. Shouldn't be too hard.
I'm willing to patch FreeBSD's rtadvd to support RFC 5006 as well, if I
can find the time.
Cheers,
MC.
--
M.C. Widerkrantz, http://hack.org/mc/
Plain text e-mail, please. OpenPGP welcome.
___
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"
