Re: IPSEC NAT traversal
--- On Wed, 5/6/09, Bjoern A. Zeeb wrote: > On Wed, 6 May 2009, Gabe wrote: > > Hi, > > I had been travelling yesterday, ... here is the summary > for today: > > > So how is it coming along? > > It's compiling; it's on might notebook since last > night as well. It > hasn't crashed yet. I haven't tested IPsec yet > either though;) > That'll probably happen the next days. Need to build a > custom > ipsec-tools port first. > Ahh, please do let us know how your IPSec testing comes along when you get to it. > > Is the goal to standardize this and commit it to > become a permanent > > part of freebsd? I've got a total of three > machines with this patch > > and would rally like it if it were. > > Stadardize as in between everyone is not going to work. > Different > people have already adopted different APIs but trying to be > as > compatible with netbsd/linux sounds like a plan. OS X is > different, > unfortunately. > I see. > Having it in FreeBSD 8.x is definitively on the schedule. > Awesome, looking forward to that. > /bz > > -- Bjoern A. Zeeb The greatest risk is > not taking one. Thanks for the reply! ___ 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: Configure networking outside rc.conf
Giulio Ferro wrote: > Chris Cowart wrote: >> Assuming the NICs are displayed by ifconfig -a or inserted into >> cloned_interfaces in /etc/rc.conf, you can create the following scripts: >> >> /etc/start_if.vlan100 >> /etc/stop_if.vlan100 >> >> Where start_if.vlan100 is sourced by the netif start and stop_if.vlan100 >> is sourced by the netif stop. >> >> For example: >> >> | ccowart dev-aux etc $ cat /etc/start_if.vlan81 >> | ifconfig vlan81 vlan 81 vlandev em0 >> | ifconfig vlan81 inet 10.81.1.1/16 >> >> I don't know that two files per interface is any cleaner than a really >> long /etc/rc.conf (I usually prefer the latter, but I generally am not >> dealing with more than 20-40 lines at most). >> >> > Thanks for the reply. > What should be normally put in the stop_if. file? Do the "stop" > files make sense? You might, for example, have a dhcp server dedicated to that interface which you wanted to start/stop as the interface goes up/down. > Anyway I'll try to make it fit with what I need. > > ___ > 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" -- Eric W. Bates er...@vineyard.net ___ 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 duplicate address detection
Bob Van Zant wrote: > Well that goes all the way back to my first email :-) > > "An alternative view on this is that I shouldn't be sending out any packets, > especially unsolicited NAs, using or referencing a tentative address." > > This makes sense. I'll stop doing bad things now :-) Thanks for your input > and clearing this up for me. > OK, I'm very glad Jinmei-san has chewed over the specifics of how this might break DAD as specified. All the same, you did find a condition in the kernel where locally-originated traffic is being interpreted as being on-wire. Ok, SOCK_RAW is going to raise the bar on malefeasant use of this behaviour, but all the same, this is an input checking issue :-) It would be great if you could go ahead and raise a PR about this condition -- the MLDv2 code in HEAD will also be affected by this, as it does an IPv6 group membership check on the icmp6 input path. Strictly speaking it should come from ip6_mloopback(), but right now I can't remember if that will set any mbuf flags; I do believe it sets m->m_pkthdr.recvif to loif and that might be the only coherent way to detect the looped back traffic w/o doing an address lookup. cheers, BMS ___ 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"
[ipfw patch - add ipv6 support for table mechanism] request for testing/commit
Hi all,
I extended the ipfw table mechanism to IPv6 protocol and now i need
some people for testing and next commit it.
The code is stable but you must be careful about possible ambiguous
parser semantics.
Now you must insert IPv6 addresses inside a table:
ipfw table 1 add fe80::1
And you can create IPv6 rules about this table:
ipfw add deny tcp from table6(1) to any dst-port 22
ipfw add deny icmp6 from any to table6(1)
The "table6" semantic tell the difference betwen the IPv4 semantic
("table").
The following changes are made on the ipfw2 sources:
KERNEL SPACE:
ip_fw.h
1) Added 2 new OPCODES: O_IP6_SRC_LOOKUP, O_IP6_DST_LOOKUP
2) Added the follow fields in "ipfw_table_entry" structure:
struct in6_addr addr6, mask6;
uint8_t proto;
ip_fw2.c
1) Added the follow fields in "struct table_entry" structure:
struct sockaddr_in6 addr6, mask6;
uint8_t proto;
2) Some changes inside the "add_table_entry" function.
3) Some changes inside the "del_table_entry" function.
4) Some changes inside the "flush_table_entry" function.
5) Some changes inside the "lookup_table" function.
6) Some changes inside the "dump_table_entry" function.
7) Added a new function named "set_proto_table".
8) Added the two new OPCODES inside the "ipfw_check()" function.
9) Added the two new OPCODES inside the "check_ipfw_struct" function.
USER SPACE:
ipfw2.c
1) Added some changes on "table_handler" function
2) Added some changes on "show_ipfw" function
3) Added some changes on "print_ip6" function
4) Added some changes on "fill_ip6" function
5) Added some changes on "add_dstip6" function
6) Added some changes on "add_srcip6" function
7) Added some changes on "add_src" function
8) Added some changes on "add_dst" function
I updated the man pages.
INSTALLATION INSTRUCTIONS:
Put the "ip_fw2.c" and "ip_fw.h" files inside the "/sys/netinet/
directory"
Put the "ipfw2.c" file inside the /src/sbin/ipfw/ directory
Rebuild the ipfw kernel module or rebuild you kernel
Rebuild the ipfw bin or the entire SBIN.
The Sources was tested on FreeBSD 7.2 Release.
Let me know any troubles
Ciao
Raffaele
___
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"
nf_sockopt_init in uipc_socket.c
Hi,
With 7.2, is ok to add the following function to the uipc_socket.c file?
void nf_sockopt_init(void)
{
LIST_INIT(&nf_sockopts);
mtx_init(&nf_sockopt_mutex,"linux netfilter lock",NULL,MTX_DEF);
}
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"
