if_bridge stops when running virtualbox 4.1.8
Hi, I just noticed that when running Virtualbox 4.1.8 with a bridged network interface, I loose connectivity to another virtual host running in qemu whose network interface is bridged to my ethernet interface. After stopping the Virtualbox instance, I regain connection to the virtual host under qemu. Ifconfig doesn't give a clue. Has anyone seen this behaviour or, even better, have a solution? My host is running 8.2-RELEASE, here's the relevant ifconfig output: em0: flags=8943 metric 0 mtu +1500 options=2098 ether 00:1f:16:xx:xx:xx inet 10.0.0.10 netmask 0xff00 broadcast 10.0.0.255 nd6 options=3 media: Ethernet autoselect (1000baseT ) status: active tap0: flags=8943 metric 0 mtu +1500 options=8 ether 00:bd:32:xx:xx:xx nd6 options=3 Opened by PID 13433 bridge0: flags=8843 metric 0 mtu 1500 ether 8a:55:3f:xx:xx:xx id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: tap0 flags=143 ifmaxaddr 0 port 5 priority 128 path cost 200 member: em0 flags=143 ifmaxaddr 0 port 1 priority 128 path cost 2 vboxnet0: flags=8802 metric 0 mtu 1500 ether 0a:00:27:00:00:00 Thanks! Paul Schenkeveld ___ 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: Multiroute question
On Thu, Sep 20, 2012 at 01:25:50PM -0400, Michael MacLeod wrote: > Actually, multiple routing tables is the correct solution. I documented it > here: > > http://www.mmacleod.ca/blog/2011/06/source-based-routing-with-freebsd-using-multiple-routing-table/ > > >From the post: "... But route-to and reply-to do not trump the default > routing table for traffic that originates or terminates on the router > itself. They are useful only for traffic passing through the router. pf can > only make routing decisions when a packet passes through an interface. It > can try and set the reply-to interface to be the second WAN connection when > an inbound SSH connection is made, but neither the SSH daemon nor the > routing table on the host know or care about the routing preferences of pf." FWIW, I've many dual-homed machined running perfectly by combining pf for filtering and ipfw for policy-based routing. Basically, ipfw is configured roughly as follows (a.b.c.0/29 is the first WAN connection and d.e.f.0/29 the second): 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 01001 allow carp from any to any 01002 allow pfsync from any to any 01100 allow ip from any to 10.0.0.0/8 01101 allow ip from any to 172.16.0.0/12 01102 allow ip from any to 192.168.0.0/16 01103 allow ip from any to 224.0.0.0/3 01110 allow ip from any to 0 allow ip from any to ... 01200 fwd a.b.c.1 ip from a.b.c.0/29 to any 01201 fwd d.e.f.1 ip from d.e.f.0/29 to any 65535 allow ip from any to any Lines 1100 thru pass all traffic that should not go out over a WAN interface, they follow the normal routing table. I need the lines 011xx because I have multiple public IP address blocks on the inside and behind tunnels. Lines 1200 and 1201 forward packets to either WAN interface depending on the source address. I also have a default gateway set to my preferred WAN interface for connections originating from this host where the client does not explicitly select a source address. This works both for packets being routed and for packets originating from the dual homes host itself. I've been using this since FreeBSD 6 and never felt the need to switch to multiple routing tables because this fits the purpose and is quite clean IMO. It's also not necessary to run multiple server processes (like sshd, sendmail, httpd) for every routing domain. With kind regards, Paul Schenkeveld ___ 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"
Carp seems completely broken on 8.2-RC2 and 8.2-PRERELEASE
elect (100baseTX )
status: active
test2 # ifconfig carp4
carp4: flags=49 metric 0 mtu 1500
inet 10.4.0.1 netmask 0xff00
carp: BACKUP vhid 104 advbase 1 advskew 100
There are no packet filters in place, sis1, sis2 and sis3 are wired
through cross-cables from test1 to test2, so no traffic there except for
carp. The sis4 interfaces and vr3 of test3 are on a dumb switch with no
other stuff connected.
Setting net.inet.carp.log=7 does not result in any console/dmesg/messages
output.
I see carp traffic on sis4 which appears normal except that I don't
understand the addrs(7): part but that used to be there on 8.0/8.1
firewalls too:
12:26:52.387140 00:00:5e:00:01:68 > 01:00:5e:00:00:12,
ethertype IPv4 (0x0800), length 70:
(tos 0x10, ttl 255, id 61070, offset 0, flags [DF],
proto VRRP (112), length 56)
10.4.0.2 > 224.0.0.18: VRRPv2, Advertisement,
vrid 104, prio 0, authtype none, intvl 1s, length 36,
addrs(7): 198.145.25.33,1.75.182.226,80.169.106.108,
170.107.157.42,147.165.174.125,42.254.15.27,182.184.82.166
12:26:53.387903 00:00:5e:00:01:68 > 01:00:5e:00:00:12,
ethertype IPv4 (0x0800), length 70:
(tos 0x10, ttl 255, id 61479, offset 0, flags [DF],
proto VRRP (112), length 56)
10.4.0.2 > 224.0.0.18: VRRPv2, Advertisement,
vrid 104, prio 0, authtype none, intvl 1s, length 36,
addrs(7): 101.233.35.135,163.243.214.16,230.125.241.59,
123.57.190.52,104.246.131.251,255.69.201.65,61.158.20.122
Regards,
Paul Schenkeveld
___
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: Carp seems completely broken on 8.2-RC2 and 8.2-PRERELEASE
On Mon, Jan 17, 2011 at 01:05:31PM +0100, Daniel Hartmeier wrote: > On Sun, Jan 16, 2011 at 01:41:22PM +0100, Paul Schenkeveld wrote: > > > There is an ARP request which is replied to by the carp master (test). > > the ping to the carp address does not even appear on the sis4 interface > > of test1. > > Everything looks fine, except for the fact that the ping (echo request) > doesn't get to test1's sis4. > > Are you sure the problem isn't with the switch? Have you tried resetting > it? Or replacing it with another one (where you could check the MAC > address table, etc.)? The switch has been power-cycled, no change. Only 3 ports are wired, to test1, test2 and test3. I'm not in the office right now, can replace the switch tonight, but read on... > You'd get this behavior if the switch had learned carp4's virtual MAC > address (00:00:5e:00:01:68) on another port. You're not using vhid 104 > (:68 in the virtual MAC) on other ports of that switch, are you? test3 has no carp nor vrrp so vhid 104 is not in use anywhere else. Tcpdump shows only carp (vrrp) packets from test1 one per second. sis3 of test1 and test2 are connected by a cross-cable. IP addresses are 10.3.0.1/24 (carp3, vhid 103, test1 is master, test2 is backup), 10.3.0.2/24 for sis3 on test1 and 10.3.0.3 for sis3 on test2. On test1 I can ping 10.3.0.1 (which test1 is carp master for), from test2 I can't ping 10.3.0.1. A tcpdump on sis3 on test1 shows ARP request and reply, but no icmp echo-request. The arp entry on test2 looks OK: test2 # arp 10.3.0.1 ? (10.3.0.1) at 00:00:5e:00:01:67 on sis3 expires in 800 seconds [ethernet] On test2 I can ping 10.3.0.2 and 10.4.0.2 (the addresses on sis3 and sis4 of test1) and see the normal arp-request/arp-reply/icmp-echoreq/ icmp-echoreply sequence using tcpdump. > Daniel Regards, Paul Schenkeveld ___ 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"
sis(4) broken on 8.2 [Re: Carp seems completely broken on 8.2-RC2 and 8.2-PRERELEASE]
On Sun, Jan 16, 2011 at 01:41:22PM +0100, Paul Schenkeveld wrote: > Hi, > > Trying to upgrade two Soekris firewalls to 8-STABLE or 8.2-PRERELEASE > it appears that carp doesn't work at all. I've set up carp like I've > done on many firewall pairs before and they all work correctly. With > google, nor in the mailing lists, I could find anything about changes > in the way carp get configured but if I missed something I'd be happy > to hear that it's my fault. > > Here's the setup: > > net5501 > test3 > 10.4.0.4/24 >| > -+- >| | > net4801 net4801 >test1 test2 > sis4: 10.4.0.2/24 sis4: 10.4.0.3/24 > carp4:10.4.0.1/24 carp4:10.4.0.1/24 >| | | | | | | | >| | | | | | | | > sis[0-3] connected to other networks, see > explanation below. > > When I ping from test3 to 10.4.0.1, I see the following traffic using > tcpdump: > > test3 # tcpdump -e -n -i vr3 not vrrp > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on vr3, link-type EN10MB (Ethernet), capture size 96 bytes > 12:09:35.121831 00:00:24:c9:30:ff > ff:ff:ff:ff:ff:ff, > ethertype ARP (0x0806), length 60: > Request who-has 10.4.0.1 tell 10.4.0.4, length 46 > 12:09:35.122144 00:00:24:c3:49:91 > 00:00:24:c9:30:ff, > ethertype ARP (0x0806), length 60: > Reply 10.4.0.1 is-at 00:00:5e:00:01:68, length 46 > 12:09:35.122173 00:00:24:c9:30:ff > 00:00:5e:00:01:68, > ethertype IPv4 (0x0800), length 98: > 10.4.0.4 > 10.4.0.1: ICMP echo request, > id 40482, seq 0, length 64 > > test1 # tcpdump -e -n -i sis4 not vrrp > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on sis4, link-type EN10MB (Ethernet), capture size 96 bytes > 12:09:34.977570 00:00:24:c9:30:ff > ff:ff:ff:ff:ff:ff, > ethertype ARP (0x0806), length 60: > Request who-has 10.4.0.1 tell 10.4.0.4, length 46 > 12:09:34.977705 00:00:24:c3:49:91 > 00:00:24:c9:30:ff, > ethertype ARP (0x0806), length 42: > Reply 10.4.0.1 is-at 00:00:5e:00:01:68, length 28 > > test2 # dump -e -n -i sis4 not vrrp > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on sis4, link-type EN10MB (Ethernet), capture size 96 bytes > 12:09:35.090050 00:00:24:c9:30:ff > ff:ff:ff:ff:ff:ff, > ethertype ARP (0x0806), length 60: > Request who-has 10.4.0.1 tell 10.4.0.4, length 46 > > There is an ARP request which is replied to by the carp master (test). > the ping to the carp address does not even appear on the sis4 interface > of test1. > > This is the kernel config for test1 and test2: > > include GENERIC > device carp > makeoptions MODULES_OVERRIDE="" > > The relevant rc.conf bits: > > on test1 > hostname="test1" > cloned_interfaces="carp1 carp2 carp3 carp4" > ifconfig_sis0="xxx.xxx.xxx.41/26" > ifconfig_sis1="10.1.0.2/24" > ifconfig_sis2="10.2.0.2/24" > ifconfig_sis3="10.3.0.2/24" > ifconfig_sis4="10.4.0.2/24" > ifconfig_carp1="10.1.0.1/24 vhid 101 pass abcd1234 advskew 0" > ifconfig_carp2="10.2.0.1/24 vhid 102 pass abcd1234 advskew 0" > ifconfig_carp3="10.3.0.1/24 vhid 103 pass abcd1234 advskew 0" > ifconfig_carp4="10.4.0.1/24 vhid 104 pass abcd1234 advskew 0" > > on test2 > hostname="test2" > cloned_interfaces="carp1 carp2 carp3 carp4" > ifconfig_sis0="xxx.xxx.xxx.42/26" > ifconfig_sis1="10.1.0.3/24" > ifconfig_sis2="10.2.0.3/24" > ifconfig_sis3="10.3.0.3/24" > ifconfig_sis4="10.4.0.3/24" > ifconfig_carp1="10.1.0.1/24 vhid 101 pass abcd1234 advskew 100" > ifconfig_carp2="10.2.0.1/24 vhid 102 pass abcd1234 advskew 100" > ifconfig_carp3="10.3.0.1/24 vhid 103 pass abcd1234 advskew 100" > ifconfig_carp4="10.4.0.1/24 vhid 104 pass abcd1234 advskew 100" > > In /etc/sysctl.conf: > net.inet.carp.preempt=1 > > Ifconfig output: > > test1 # ifconfig sis4 > sis4: flags=8943 met
Re: sis(4) broken on 8.2 [Re: Carp seems completely broken on 8.2-RC2 and 8.2-PRERELEASE]
Hello, On Mon, Jan 17, 2011 at 02:26:24PM -0800, Pyun YongHyeon wrote: > > Since you didn't post dmesg output I'm not sure what kind of > > controller you have but I guess it would be NS8381[56]. I > > overhauled sis(4) to make it work on all architectures so one of > > change, probably r212119, could be cause of the issue. Due to lack > > of SiS controllers I didn't touch multicast handling part so some > > part of code still relies on old wrong behavior of driver. > > Would you try attached patch and let me know whether it makes any > > difference? > > > > Hmm, unfortunately it seems the patch above may not work since NS > data sheet says that filter function should be disabled before > touching other bits in the register. > Try this one instead. As far as I can tell, both patches work for me. Your second patch is on my production firewalls now so if anthing comes up over the coming days I'll keep you informed. I've tested carp, both failover to backup and fallback (preemption) with IPv4 and with IPv6, all seems to work now. Thannks again for your patches, hope you can get them into 8.2. Regards, Paul Schenkeveld ___ 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"
rtadvd and carp
Hi, I'm trying to enable IPv6 troughout the whole network here but I'm stuck on configuring rtadvd on my redundant firewall. The firewall consists of two Soekris net5501 (with 4 additional network interfaces each). Sis0 is connected to a LAN where I'd like to use IPv6, carp0 is my virtual interface. If I enable rtadvd on sis0 on both firewalls I see they both advertise the autoconf address of sis0 as the default gateway. I'd like the IPv6 address of carp0 to be advertised, can rtadvd do that or should I go for an IPv6 enable DHCP server? Thanks. Paul Schenkeveld ___ 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"
Multiple IPv6 ISPs
Hi, At one of my customers we have had 2 ISPs for a long time but now we have to support IPv6 too. In the IPv4 world I used ipfw for policy-based routing to separate traffic from the two public address ranges: ipfw add 1010 allow ip from any to MY_IP_RANGES ipfw add 1020 fwd ISP1_GW ip from ISP1_SUBNET to any ipfw add 1030 fwd ISP2_GW ip from ISP2_SUBNET to any When I try the same with IPv6, it appears that ipfw(8) does not support an IPv6 destination with the fwd statement, the packet matching part seems to work fine. This appears documented in bin/117214 (Oct 2007) but never solved. Before asking the list I went looking for other options, setfib came to mind but it appears that setfib only works on IPv4, is that correct or am I overlooking something? Pf is used for firewalling and doing both filtering and policy based routing in pf doesn't work. Anyway, how do other people solve this? I need to run services on both address ranges so flipping a default gateway when pinging the next hop fails does not solve it for me. Soon, having IPv6 is no longer an option but rather a necessity. Regards, Paul Schenkeveld ___ 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"
Bridging wlan to gif?
Hi, I'm trying to bridge a wlan interface to a gif tunnel on 8.0-BETA2. Running tcpdump on wlan0 I see DHCP packets coming in as IP packets, on gif0 however tcpdump shows ethernet headers prepended. Needless to say things do not work as expected. What I try to accomplish is the following: +--+ +--+ +---+ | | |ath0 bge0|-|Router | Gateway | | |wlan0 gif0| +---++--+ | | | \ /| || gif0| | | | bridge0 | Internet|\ | | | | | || bridge0 | +--+ +--+ +---+| \ | Wifi Access point |Router ||fxp0 fxp1| LAN X client 8.0-BETA2 +---++--+ - The Wifi client must be part of LAN X and receive a DHCP address from a DHCP server (not shown) on LAN X - On the access point wlan0 and gif0 are bridged together - On the gateway fxp1 and gif0 are bridged together - Gif0 on the access point and gif0 on the gateway communicate correctly when given IP addresses Regards, Paul Schenkeveld ___ 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: Using netgraph for filtering/modifing packets
On Mon, Jun 14, 2004 at 01:28:06PM -0400, James Housley wrote: > Julian Elischer wrote: > > > >On Mon, 14 Jun 2004, James Housley wrote: > > > > > >>For testing of a product I would like to be able to modify or even drop > >>packets based on their content. What I have in mind is forcing the > >>packets through a firewall that would redirect all packet to a netgraph > >>node that would either pass unchanged, drop or change the contents to > >>assist in testing some corner cases in the code. > >> > >>1) is this something doable with netgraph, I believe it is. > > > > > >yes > > > > > > > >>2) what might be a good place to start? Have done some searching, but > >>haven't found any example code I thought I could start from. > > > > > >What sort of filter do you need? > > > >you can pass packets to netgraph from ipfw by diverting them and > >openning a divert socket with teh ksocket node.. > > > >Or you can pick them directly from the network interface > >and filter yourself using the 'bpf' node type to select > >on something. > >or you can use the etf type of node to filter on a particular > >ethertype.. > > > >there are a lot of options but I don't knw your application enough :-) > > > > I have a product that is connected to a PC via eithernet. The product > runs FBSD, but I would likely put another FBSD box in the middle. I want > to be able modify packets for good and evil based on the data portion of > the packet. > > For example to ocasionally drop a packet that is acking some command. Or > send an ack for a command that was never sent. Or just change data to be > invalid. > > Then after messing with the data portion put it back in the queue to be > sent, if it wasn't just dropped. If you are talking about a TCP based protocol and you want to change the conversation between the client and the server, you probably don't want to drop or alter packets at the network level or you'd have to recalculate sequence numbers and checksums. To modify the client-server conversation (e.g. to see if evil clients can hack your server) it might be much easier to write a small application level proxy to alter or drop packets. With TCP based protocols this is (I think) the easiest solution, with UDP is is probably a bit easier than the netgraph approach. > > Jim Regards, Paul Schenkeveld, Consultant PSconsult ICT Services BV ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: spoofed MAC on a dhcp interface
Hi, On Sun, Jul 25, 2004 at 05:52:57PM -0700, Charlie Schluting wrote: > Hi :) > > /etc/rc.conf: > ifconfig_xl0="ether 00:11:11:11:11:11" > ifconfig_xl0="DHCP" The last assignment takes precedence over the previous one. > The above doesn't work.. > I'm trying to set the mac, and then dhcp.. is this the correct way? Set iconfig_xl0="DHCP" in rc.conf, then use a /etc/start_if.xl0 script to set the MAC address: #!/bin/sh ifconfig xl0 ether 00:11:11:11:11:11 > With this config, its not getting the mac assigned to xl0, so I have to > stop dhclient, run "ifconfig ether 00:11:11:11:11:11" manually, then > dhcp again. > > Thanks! > -Charlie $0.02 Regards, Paul Schenkeveld, Consultant PSconsult ICT Services BV ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: question on tunnels (VPN)
On Wed, Sep 22, 2004 at 04:17:59PM +, Mikhail P. wrote: > Dear users, > > I have been experimenting with simple gif tunnels (no IPSec) in local network > (192.168.0.0/24). I have used the following scenario between two hosts (both > running FreeBSD-5.2.1): > > HOST_A [192.168.0.1]: > ifconfig gif0 create > ifconfig gif0 tunnel 192.168.0.1 192.168.0.2 > ifconfig gif0 10.0.0.1 10.0.0.2 netmask 255.255.255.255 > > and on - > > HOST_B [192.168.0.2]: > ifconfig gif0 create > ifconfig gif0 tunnel 192.168.0.2 192.168.0.1 > ifconfig gif0 10.0.0.2 10.0.0.1 netmask 255.255.255.255 > > The above works well for me, and I can send traffic on 10.0.0.1 and 10.0.0.2. > > The next thing I wanted to implement is to create similar tunnel from our > local router (which is FreeBSD too) to remote server, however there is small > problem which stops me - router has no public IP, and it sees internet > through DSL router, so basically that router is NAT'ed behind DSL router. > As far as I understand, it appears to be that I won't be able to create such a > simple tunnel, unless my router gets public IP address. > > What I tried next was MPD pptp link (which is known to work behind NAT, unlike > above example), but something (ISP? DSL router?) cuts GRE packets on their > way, so MPD can't establish LCP connection with remote host. > > I'm now in loss as to what to try next - could someone please advise what > other techniques will work in my scenario (where I want to connect machine > which is behind NAT and no GRE packets will go through)? Have a look at /usr/ports/net/vtun. It allows you to create tunnels over virtually any transport you can find including TCP and UDP (but also raw IP, serial lines, ssh tunnels ...). Tunnel endpoints are tunN devices. It has built in encryption (openssl) en compression (lzo, zlib and even a traffic shaper. > regards, > M. HTH Paul Schenkeveld, Consultant PSconsult ICT Services BV ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPsec / ipfw interaction in 4.7-STABLE: a proposed change
On Fri, Jan 03, 2003 at 12:04:59PM +0200, Pekka Nikander wrote: > Eric Masson wrote: > > Seems pretty close to what OpenBSD has implemented, except they don't > > use the stock loopback interface. > > > > Their enc(4) driver is a software loopback interface : > > >http://www.openbsd.org/cgi-bin/man.cgi?query=enc&sektion=4&arch=i386&apropos=0&manpath=OpenBSD+Current > > Thanks for the pointer! > > > It's used in src/sys/netinet/ipsec_input.c to impersonate the incoming > > interface just as you did in your patch. > > > > I'd like to know whether there would be any interest in associating a > > different interface to each incoming SPD entry or just use only one > > interface for all incoming SPD entries ? > > Well, IMHO the best way would be to have a separate interface > for each tunnel end point. That would allow most fine grained > control, and would be easiest to understand. > > Perhaps something like the following: > >ifconfig enc0 up >ifconfig enc0 192.168.0.129 netmask 255.255.255.0 >ifconfig xl1 192.168.0.130 netmask 255.255.255.128 > >setkey -c << EOF >spdadd 192.168.0.0/24 192.168.0.128/25 any -P in > ipsec esp/tunnel/XXX-YYY/require; >spdadd 192.168.0.128/25 192.168.0.0/24 any -P out > ipsec ESP/tunnel/YYY-XXX/require; >EOF > > Even better would be if you could use just on IP address > instead of having a separate address at the tunnel > interface and another one at the internal network interface, > but I'm not sure if that would work. Because of the way IPsec and ipfw/ipfilter interact, I've moved to the following workaround: ifconfig fxp0 $my_internal netmask $my_internal_netmask ifconfig gif0 create \ tunnel $my_external $peer_external \ $my_internal $peer_external Now I use transport mode instead of tunnel mode between the two external IP addresses: setkey -c << EOF add $my_external $peer_external ah spi1 -A hmac-md5 key1; add $peer_external $my_external ah spi2 -A hmac-md5 key2; add $my_external $peer_external esp spi3 -E blowfish-cbc key3; add $peer_external $my_external esp spi4 -E blowfish-cbc key4; spdadd $my_external $peer_external ipencap -P out ipsec esp/transport/$my_external-$peer_external/require ah/transport/$my_external-$peer_external/require; spdadd $peer_external $my_external ipencap -P in ipsec esp/transport/$peer_external-$my_external/require ah/transport/$peer_external-$my_external/require; EOF The 'ipencap' in the spadd lines causes only traffic in the gif tunnel to be affected by IPsec, you could also use 'any' here to encrypt/sign all traffic. Now all tunnel traffic (in and out) passed gif0 where I can use ipfw and/or ipfilter. Although this is not the solution to your problem, it shows a behaviour close to what you want I think. I'd love to see ipsec evolve in a way that I don't need gif tunnels anymore so I like the enc0 interface concept but then I'd suggest that IPsec automagically create route entries from the spadd lines such that also outbound traffic passes enc0. > When IPsec is not used or properly configured, the enc > interface could be just a black hole, discarding any > packets that are not processed and tunneled by IPsec. > > With the received packets, the IPsec code would need to > go through the configured enc interfaces, and find one > where the source address would match... > > Now, all this has one not-so-good design aspect: in a way > you need to configure the tunnel twice: once the enc > interface, IP addresses and routing etc, and a second time > set up the proper IPsec SPD entries. Perhaps the enc > interface could be even more intelligent, and set up default > SPD entries based on routing tables??? > > --Pekka Nikander -- Paul Schenkeveld, Consultant PSconsult ICT Services BV To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: IPsec / ipfw interaction in 4.7-STABLE: a proposed change
On Fri, Jan 03, 2003 at 01:36:28PM +0200, Pekka Nikander wrote: > Paul Schenkeveld wrote: > > Because of the way IPsec and ipfw/ipfilter interact, I've > > moved to the following workaround: > ... > > Now I use transport mode instead of tunnel mode between the two > > external IP addresses: > ... > > Although this is not the solution to your problem, it shows a > > behaviour close to what you want I think. > > Thanks for the suggestion, but I'm afraid that it won't work > for me. Namely, my ISP has a NAT box between my home server > and the rest of the internet. Fortunately I do have a permanent > one-to-one mapping at the NAT box so that I can run ESP over it, > and with manually set up tunnel ESP it works. Not nice, but it > works. I'm afraid transport mode wouldn't work, but maybe > I should try it. If ESP in tunnel mode works for you I think ESP in transport mode should also work. Note that in my example, the transport mode is not configured between the internal addresses but between the external addresses of the two tunnel endpoints. I chose to only ESP gif packets (the ipencap keyword) but you could alse ESP all packets by replacing ipencap by any. > > I'd love to see ipsec evolve in a way that I don't need gif tunnels > > anymore so I like the enc0 interface concept but then I'd suggest > > that IPsec automagically create route entries from the spadd lines > > such that also outbound traffic passes enc0. > > I think that generating routing table entries from SPD is > probably a better idea than my original idea of doing > it the other way around. I think that it would be even possible > to do that in the user land, having some process listening to > a PFKEY socket and adding and deleting routes as it sees > tunnel mode SPD entries coming and going. I forgot to mention that this enc0 kind of interface should allow to specify the interface name per tunnel. If you have multiple tunnels (like I do) configuring ipfw/ipf would be a nightmare if the enc* interface is assigned randomly. > --Pekka Nikander -- Paul Schenkeveld, Consultant PSconsult ICT Services BV To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Source Routing
On Wed, Dec 31, 2003 at 03:48:11AM -0800, afshin wrote: > You know I Use ipf with for example pass xl1:1.2.3.4 > from 1.2.3.5/24 to any > BUT, The Problem is that when I use this, the 1.2.3.5 > cannot access the local IPs, > Without looking at routing tables of the router it > QUICKLY passes it to the NEW gateway. FWIW, I usually do all filtering using ipf but at one site I'm administering I had to do source routing so I implemented the routing part with ipfw and the (stateful) filtering with ipf. This works great there. If needed, I can dig up some config next week and post it here. Regards, Paul Schenkeveld, Consultant PSconsult ICT Services BV > Thanks > AFShhin > > > --- Ruslan Ermilov <[EMAIL PROTECTED]> wrote: > > On Tue, Dec 30, 2003 at 11:25:46AM -0800, afshin > > wrote: > > > > > > > What is missing in ipfw(8) and its ``fwd'' > > option > > > > from being a > > > > successful implementation of policy routing? > > > > > > > > - by using the match probability feature, you > > can > > > > implement > > > > the equal-access routing; > > > > > > > > - by checking the source IP adress, you can > > > > implement > > > > the source-sensitive routing; > > > > > > > > - by checking the IP TOS field, you can > > implement > > > > the > > > > quality-of-service routing; > > > > > > > > - etc. > > > > > > > > > > Dear Ruslan, > > > Yes, That is what I really want, But it didn't > > worked > > > when I tried it. > > > Would you mind please give me an working example > > of it > > > ? > > > Really thank you all in advance, > > > AFShin (AAS) > > > > > Sorry, but I don't have one to share. Those that I > > have > > are proprietary. But we could work with your > > examples > > to a level to make them work. ;) > > > > > > Cheers, > > -- > > Ruslan Ermilov > > FreeBSD committer > > [EMAIL PROTECTED] > > > > > ATTACHMENT part 2 application/pgp-signature > > > > __ > Do you Yahoo!? > Find out what made the Top Yahoo! Searches of 2003 > http://search.yahoo.com/top2003 > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Strange routing configuration problem
On Sun, Feb 01, 2004 at 05:20:43AM -0500, Sandeep kumar Davu wrote: > I have 3 machines running freebsd 4.5. I want to configure one of as a router. > One machine (A) has a IP of 131.123.36.65 (dc0). This needs to be connected to > another machine (B) 131.123.36.102 (ed1)through a machine (R) that has two > network cards 131.123.36.98(dc0) and 131.123.36.101(dc1). The netmask for the > every ip is 255.255.255.192 (CANT CHANGE THIS). Given your netmask, both IP addresses of R are in the same subnet as machine B. The card in R which is on the same subnet as A should have an IP address between 131.123.36.66 and 131.123.36.94. > I am able to ping A to R, R to A. Firstly I could not ping B to R. I figured > out that B was unable to find the lladdr or R and added a static route in R. > > $route add 131.123.36.102 -interface dc1 > $arp -s 131.123.36.102 _ll_addr_ > > Doing so I could ping from R to B. > > Now heres the problem > >From B I can ping to one interface of R dc1. But I cannot get to the other > interface dc0 nor to A. > > I have configured the machine R to be a router. gateway_enable="YES" > router_enable ="YES" > > Even this did not help at all. I dont know where I am doing a mistake. > There is something that needs to be filled in. > Can anyone please help me here. > I am stuck in this for days. > > Regards > sandeep Regards, Paul Schenkeveld, Consultant PSconsult ICT Services BV ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: do we support non contiguous netmasks ?
Hi, On Tue, Apr 06, 2004 at 03:27:36PM +0200, Anders Lowinger wrote: > I was just trying to elaborate on when/why non-contignous netmasks > would be good to have. I'm pretty sure no-one is using them Actually, one of my customers uses a non-contiguous netmask for static routes. The picture is something like this: In a WAN they have many branch offices with a standardized IP plan giving 8 subsequent /24 subnets (RFC1918) to each branch. At one point in time it was decided that the second subnet of each branch office should use an ISDN dialup network instead of the VPN because the traffic on that subnet is only occasional but too bursty for the VPN. So the IP plan is: 172.18.bsss. (branches 1 - 32) 172.19.bsss. (branches 33 - 64) where b is the branch office number (module 32) and sss the subnet number within the branch office. They have the following two routes on their central (FreeBSD) routers at the main office: route add -net 172.18.0.0 -netmask 255.254.0.0 vpn-router route add -net 172.18.1.0 -netmask 255.254.7.0 isdn-router Not having non-contiguous netmask would require them to install 65 static routes: route add -net 172.18.0.0 -netmask 255.254.0.0 vpn-router route add -net 172.18.1.0 -netmask 255.255.255.0 isdn-router route add -net 172.18.2.0 -netmask 255.255.255.0 isdn-router route add -net 172.18.3.0 -netmask 255.255.255.0 isdn-router ... route add -net 172.19.255.0 -netmask 255.255.255.0 isdn-router I agree that this use of non-contiguous netmasks is rare and I would not object against removing them from FreeBSD if is serves the purpose of better/faster/easier to understand/higher quality/easier to maintain kernel code (and tell my customer that I'm sorry but we move to 65 static routes up from 2). Greetings, Paul Schenkeveld, Consultant PSconsult ICT Services BV ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
