Re: sndiod and midicat routing issue.
On Sun, Jan 15, 2023 at 07:35:49PM +0100, Brian Durant wrote: > On 1/15/23 12:26, Alexandre Ratchov wrote: > > On Sun, Jan 15, 2023 at 09:38:38AM +0100, Brian Durant wrote: > > > The following command will connect a USB MIDI device: > > > > > > $ midicat -d -q midi/0 -q midithru/0 & > > > > > > A second device can be connected as follows: > > > > > > $ midicat -d -q midi/1 -q midithru/1 & > > > > > > Both output MIDI code in the terminal. (Note that redirecting both MIDI > > > devices to midithru/0 doesn’t seem to pipe both devices through, but > > > rather > > > only midi/0.) Adding the following command provides a way to convert MIDI > > > code to sound using Fluidsynth: > > > > Redirecting two ports to midithru/0 is supposed to work: > > > > $ midicat -d -q midi/0 -q midithru/0 # in one terminal > > $ midicat -d -q midi/1 -q midithru/0 # in another terminal > > > > should merge the two inputs. Both terminals should show the events of > > the corresponding input. If there's a synth on midithru/0 > > (ex. fluidsynth command below is running) it will produice sounds for > > both inputs. > > Hmm. Seems to be working now. However, this just means that MIDI signals go > from both MIDI devices to one instance of fluidsynth. This of course means > that both devices are sending MIDI code to one soundfont instrument. If run > as: > > $ midicat -d -q midi/0 -q midithru/0 > > and > > $ midicat -d -q midi/1 -q midithru/1 > > MIDI input could be used to play different soundfont instruments - one for > midi/0 and one for midi/1. Possibly something with the Fluidsynth "-L" > option? IIRC, you need "-p midithru/1" for the second fluidsynth instance. > The problem is the same for LMMS. However, only one MIDI input is > ever available. Enabling MIDI input and choosing different channels for SF2 > Player and Kicker do not provide a second MIDI input to choose from when the > clicking the relevant plugin's gear icon in the "song editor" window. Not > even when running midicat as I have suggested above. Hopefully this won't > raise any hackles me writing this, but what I am describing is the normal > expectation for using MIDI under Windows, Mac and Linux... I realize that > this is achieved in various ways depending on the OS, but particularly the > expected use case scenario that I describe for LMMS provides some challenges > in OpenBSD. I don't use lmms very often, but I'd recommend you to configure your keyboards to use different channels (ex. 0 and 1) and route both of them to midithru/0. Then, in LMMS, for each track select the appropriate channel: click on the piano icon, check "enable midi input" and select the desired channel number (mind lmms counts starting from 1, so it would be 1 and 2 respectively). This way each plugin will get the input from the desired keyboard. AFAIU, LMMS supports only one MIDI input, so you've to use channels if you need to wire different keyboards to different plugins. HTH
Re: sndiod and midicat routing issue.
On 1/15/23 12:26, Alexandre Ratchov wrote: On Sun, Jan 15, 2023 at 09:38:38AM +0100, Brian Durant wrote: The following command will connect a USB MIDI device: $ midicat -d -q midi/0 -q midithru/0 & A second device can be connected as follows: $ midicat -d -q midi/1 -q midithru/1 & Both output MIDI code in the terminal. (Note that redirecting both MIDI devices to midithru/0 doesn’t seem to pipe both devices through, but rather only midi/0.) Adding the following command provides a way to convert MIDI code to sound using Fluidsynth: Redirecting two ports to midithru/0 is supposed to work: $ midicat -d -q midi/0 -q midithru/0 # in one terminal $ midicat -d -q midi/1 -q midithru/0 # in another terminal should merge the two inputs. Both terminals should show the events of the corresponding input. If there's a synth on midithru/0 (ex. fluidsynth command below is running) it will produice sounds for both inputs. Hmm. Seems to be working now. However, this just means that MIDI signals go from both MIDI devices to one instance of fluidsynth. This of course means that both devices are sending MIDI code to one soundfont instrument. If run as: $ midicat -d -q midi/0 -q midithru/0 and $ midicat -d -q midi/1 -q midithru/1 MIDI input could be used to play different soundfont instruments - one for midi/0 and one for midi/1. Possibly something with the Fluidsynth "-L" option? The problem is the same for LMMS. However, only one MIDI input is ever available. Enabling MIDI input and choosing different channels for SF2 Player and Kicker do not provide a second MIDI input to choose from when the clicking the relevant plugin's gear icon in the "song editor" window. Not even when running midicat as I have suggested above. Hopefully this won't raise any hackles me writing this, but what I am describing is the normal expectation for using MIDI under Windows, Mac and Linux... I realize that this is achieved in various ways depending on the OS, but particularly the expected use case scenario that I describe for LMMS provides some challenges in OpenBSD. $ fluidsynth /usr/local/share/generaluser-gs/GeneralUser_GS.sf2 However, this only works for midi/0. The same is the case when using LMMS with SF2 Player and Kicker. I can get sound with SF2 Player or Kicker, but there again appears no way to connect the second device to the second plugin. Connecting two MIDI devices (or one device with keys and pads on two channels) is not an unusual use case scenario, so I am assuming that there is a solution without having to resort to midish.
Re: sndiod and midicat routing issue.
On Sun, Jan 15, 2023 at 09:38:38AM +0100, Brian Durant wrote: > The following command will connect a USB MIDI device: > > $ midicat -d -q midi/0 -q midithru/0 & > > A second device can be connected as follows: > > $ midicat -d -q midi/1 -q midithru/1 & > > Both output MIDI code in the terminal. (Note that redirecting both MIDI > devices to midithru/0 doesn’t seem to pipe both devices through, but rather > only midi/0.) Adding the following command provides a way to convert MIDI > code to sound using Fluidsynth: Redirecting two ports to midithru/0 is supposed to work: $ midicat -d -q midi/0 -q midithru/0 # in one terminal $ midicat -d -q midi/1 -q midithru/0 # in another terminal should merge the two inputs. Both terminals should show the events of the corresponding input. If there's a synth on midithru/0 (ex. fluidsynth command below is running) it will produice sounds for both inputs. > > $ fluidsynth /usr/local/share/generaluser-gs/GeneralUser_GS.sf2 > > However, this only works for midi/0. The same is the case when using LMMS > with SF2 Player and Kicker. I can get sound with SF2 Player or Kicker, but > there again appears no way to connect the second device to the second > plugin. Connecting two MIDI devices (or one device with keys and pads on two > channels) is not an unusual use case scenario, so I am assuming that there > is a solution without having to resort to midish. >
sndiod and midicat routing issue.
The following command will connect a USB MIDI device: $ midicat -d -q midi/0 -q midithru/0 & A second device can be connected as follows: $ midicat -d -q midi/1 -q midithru/1 & Both output MIDI code in the terminal. (Note that redirecting both MIDI devices to midithru/0 doesn’t seem to pipe both devices through, but rather only midi/0.) Adding the following command provides a way to convert MIDI code to sound using Fluidsynth: $ fluidsynth /usr/local/share/generaluser-gs/GeneralUser_GS.sf2 However, this only works for midi/0. The same is the case when using LMMS with SF2 Player and Kicker. I can get sound with SF2 Player or Kicker, but there again appears no way to connect the second device to the second plugin. Connecting two MIDI devices (or one device with keys and pads on two channels) is not an unusual use case scenario, so I am assuming that there is a solution without having to resort to midish. I am using a Keith McMillen K-Board and a KORG nanoPAD2, as they are both class compliant, however any class compliant devices at hand should work... Cheers, Brian
Re: multihomed routing issue
Try something like this in pf.conf: pass in on hvn1 proto tcp from to (hvn1) port 22 reply-to 10.0.0.1@hvn1 The reason you have to do this is because you have the same router address on hvn0 and hvn1 (10.0.0.1). Another option is to use route tables. Let me know if you have any questions. I run a lot of OpenBSD in Azure. -Brian > On Apr 26, 2020, at 12:03 PM, 4642 <4...@protonmail.com> wrote: > > Hi, I have created a OpenBSD 6.6 VM in the Azures cloud that I plan to use > as a Firewall, I had planned on using carp but I can't get it working in > Azure so I think I can use an Internal load balancer to achieve my aim of > having two redundany OBSD Firewalls in Azure. The problem I have is that the > Azure Internal Load Balancer requires a health probe to work. So I create a > load balancer health probe and set it to the SSH service on my FW Host and > set it to every 5 seconds. I can see the traffic on my FW but the health > probe doesn't work and I think it's because the traffic from the Azure > discover ip "168.63.129.16" that is doing the probe is coming from within the > azure nextwork, hitting my internal nic and then onto the ssh service ? and > then finally leaving but on the external interface. > > tcpdump -n -e -ttt -i pflog0 -v > tcpdump: WARNING: snaplen raised from 116 to 160 > tcpdump: listening on pflog0, link-type PFLOG > Apr 26 15:59:30.082436 rule 1/(match) [uid 0, pid 44293] block out on hvn0: > [orig src 10.x.x.36:22, dst 168.63.129.16:54762] 10.x.x.4.65324 > > 168.63.129.16.54762: S [bad tcp cksum 9d0b! -> 9e14] 252441079:252441079(0) > ack 3958895254 win 16384 (DF) (ttl 64, > id 2960, len 52, bad ip cksum 0! -> 52f0) > > Rule 1 = block log all > 168.63.129.16 = Azure Discovery Address > 10.x.x.4 = My External IP on hvn0 > 10.x.x.36 = My Internal IP on hvn1 > > I tried changing the state rules to allow the traffic out on the external > interface and I thought I had it working earlier today by changing > state-policy from if-bound to floating but I can't reproduce that again for > some reason... anyway it didn't seem to work. > I think I really just need to force the traffic back out the Internal > interface but I just don't know how to do that ? > > If anyone could help me it would be really appreciated. > Thanks > > Keith
Re: multihomed routing issue
what exactly are you trying to achieve, or: why not use azure firewall? On 26.04.20 17:27, 4642 wrote: > Hi, I have created a OpenBSD 6.6 VM in the Azures cloud that I plan to use as > a Firewall, I had planned on using carp but I can't get it working in Azure > so I think I can use an Internal load balancer to achieve my aim of having > two redundany OBSD Firewalls in Azure. The problem I have is that the Azure > Internal Load Balancer requires a health probe to work. So I create a load > balancer health probe and set it to the SSH service on my FW Host and set it > to every 5 seconds. I can see the traffic on my FW but the health probe > doesn't work and I think it's because the traffic from the Azure discover ip > "168.63.129.16" that is doing the probe is coming from within the azure > nextwork, hitting my internal nic and then onto the ssh service ? and then > finally leaving but on the external interface. > > tcpdump -n -e -ttt -i pflog0 -v > tcpdump: WARNING: snaplen raised from 116 to 160 > tcpdump: listening on pflog0, link-type PFLOG > Apr 26 15:59:30.082436 rule 1/(match) [uid 0, pid 44293] block out on hvn0: > [orig src 10.x.x.36:22, dst 168.63.129.16:54762] 10.x.x.4.65324 > > 168.63.129.16.54762: S [bad tcp cksum 9d0b! -> 9e14] 252441079:252441079(0) > ack 3958895254 win 16384 (DF) (ttl 64, > id 2960, len 52, bad ip cksum 0! -> 52f0) > > Rule 1 = block log all > 168.63.129.16 = Azure Discovery Address > 10.x.x.4 = My External IP on hvn0 > 10.x.x.36 = My Internal IP on hvn1 > > I tried changing the state rules to allow the traffic out on the external > interface and I thought I had it working earlier today by changing > state-policy from if-bound to floating but I can't reproduce that again for > some reason... anyway it didn't seem to work. > I think I really just need to force the traffic back out the Internal > interface but I just don't know how to do that ? > > If anyone could help me it would be really appreciated. > Thanks > > Keith
multihomed routing issue
Hi, I have created a OpenBSD 6.6 VM in the Azures cloud that I plan to use as a Firewall, I had planned on using carp but I can't get it working in Azure so I think I can use an Internal load balancer to achieve my aim of having two redundany OBSD Firewalls in Azure. The problem I have is that the Azure Internal Load Balancer requires a health probe to work. So I create a load balancer health probe and set it to the SSH service on my FW Host and set it to every 5 seconds. I can see the traffic on my FW but the health probe doesn't work and I think it's because the traffic from the Azure discover ip "168.63.129.16" that is doing the probe is coming from within the azure nextwork, hitting my internal nic and then onto the ssh service ? and then finally leaving but on the external interface. tcpdump -n -e -ttt -i pflog0 -v tcpdump: WARNING: snaplen raised from 116 to 160 tcpdump: listening on pflog0, link-type PFLOG Apr 26 15:59:30.082436 rule 1/(match) [uid 0, pid 44293] block out on hvn0: [orig src 10.x.x.36:22, dst 168.63.129.16:54762] 10.x.x.4.65324 > 168.63.129.16.54762: S [bad tcp cksum 9d0b! -> 9e14] 252441079:252441079(0) ack 3958895254 win 16384 (DF) (ttl 64, id 2960, len 52, bad ip cksum 0! -> 52f0) Rule 1 = block log all 168.63.129.16 = Azure Discovery Address 10.x.x.4 = My External IP on hvn0 10.x.x.36 = My Internal IP on hvn1 I tried changing the state rules to allow the traffic out on the external interface and I thought I had it working earlier today by changing state-policy from if-bound to floating but I can't reproduce that again for some reason... anyway it didn't seem to work. I think I really just need to force the traffic back out the Internal interface but I just don't know how to do that ? If anyone could help me it would be really appreciated. Thanks Keith
Multihomed IPSec routing issue
Hi, I've successfully set up the IPSec tunnel and the remote side can connect to both our public ip. As a result, 4 SAs are being created. Data is received on both inbound SAs, but I can only send packets to one outbound SA, depending on which one is established first. If I remove such SA via "ipsectl -d " the other one will be used immediately, but I would like to do so without deleting it because it will take some time before the remote side realizes this and negotiates new SAs. Is this possible? Thanks -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
Re: Routing issue with multiple interface on the same network.
i do not think it is. it makes no sense to have the same network on two interface, this way, IMHO. On Fri, Apr 22, 2016 at 1:25 PM, Jean-Daniel Dupas wrote: > Hello, > > I'm trying to configure a machine with multiple interface on the same > network > (one standard interface and one carp interface). > > My problem is that if I set the default routing table to the second > interface, > the system can't find it and return "no route" for any distant address > resolution. > > The problem occurs even when using to standard iface (so carp is not > involved). > > Note that my configuration works perfectly well on OpenBSD 5.7. I did test > the > problem with 5.9 and current, and both fail. > > > Here is my configuration: > > --- ifconfig > lo0: flags=8049 mtu 32768 > priority: 0 > groups: lo > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 > inet 127.0.0.1 netmask 0xff00 > vio0: flags=8843 mtu 1500 > lladdr 52:54:00:9e:b2:2b > priority: 0 > media: Ethernet autoselect > status: active > inet 10.0.1.2 netmask 0x broadcast 10.0.255.255 > vio1: flags=8843 mtu 1500 > lladdr 52:54:00:fd:df:4c > priority: 0 > media: Ethernet autoselect > status: active > inet 192.168.0.11 netmask 0xff00 broadcast 192.168.0.255 > vio2: flags=8843 mtu 1500 > lladdr 52:54:00:d0:e8:1d > priority: 0 > groups: egress > media: Ethernet autoselect > status: active > inet 192.168.0.12 netmask 0xff00 broadcast 192.168.0.255 > > > --- route -n show > Routing tables > > Internet: > DestinationGatewayFlags Refs Use Mtu Prio > Iface > default192.168.0.1UGS0 46 - 8 > vio2 > 10.0/1610.0.1.2 UC 3 26 - 4 > vio0 > 10.0.0.1 00:00:5e:00:01:01 UHLc 0 59 - 4 > vio0 > 10.0.1.2 52:54:00:9e:b2:2b UHLl 0 34 - 1 > vio0 > 10.0.1.15 52:54:00:0e:62:c7 UHLc 0 16 - 4 > vio0 > 10.0.3.10 ac:87:a3:1d:3f:9d UHLc 1 16 - 4 > vio0 > 10.0.255.255 10.0.1.2 UHb00 - 1 > vio0 > 127.0.0.1 127.0.0.1 UHl0 192 32768 1 lo0 > 192.168.0/24 192.168.0.11 UCP17 - 4 > vio1 > 192.168.0/24 192.168.0.12 UCP00 - 4 > vio2 > 192.168.0.1link#2 UHLc 0 25 - 4 > vio1 > 192.168.0.11 52:54:00:fd:df:4c UHLl 0 16 - 1 > vio1 > 192.168.0.12 52:54:00:d0:e8:1d UHLl 03 - 1 > vio2 > 192.168.0.255 192.168.0.11 UHPb 00 - 1 > vio1 > 192.168.0.255 192.168.0.12 UHPb 00 - 1 > vio2 > > Internet6: > DestinationGatewayFlags > Refs > Use Mtu Prio Iface > ::1::1UHl > 0 > 0 32768 1 lo0 > fe80::1%lo0fe80::1%lo0UHl > 0 > 0 32768 1 lo0 > ff01::%lo0/32 ::1UC >0 > 1 32768 4 lo0 > ff02::%lo0/32 ::1UC >0 > 1 32768 4 lo0 > > > -- ping 8.8.8.8 > PING 8.8.8.8 (8.8.8.8): 56 data bytes > ping: sendto: No route to host > ping: wrote 8.8.8.8 64 chars, ret=-1 > ping: sendto: No route to host > ping: wrote 8.8.8.8 64 chars, ret=-1 > --- 8.8.8.8 ping statistics --- > 2 packets transmitted, 0 packets received, 100.0% packet loss > [1]81614 exit 1 ping 8.8.8.8 > > If I change the default route to vio1, it works. The problem occurs only > when > the default route is on the second interface (vio2, or carp0 in my cases). > > Can someone confirm this is a bug in the routing system ? > > Regards > Jean-Daniel. > > -- - () ascii ribbon campaign - against html e-mail /\
Routing issue with multiple interface on the same network.
Hello, I'm trying to configure a machine with multiple interface on the same network (one standard interface and one carp interface). My problem is that if I set the default routing table to the second interface, the system can't find it and return "no route" for any distant address resolution. The problem occurs even when using to standard iface (so carp is not involved). Note that my configuration works perfectly well on OpenBSD 5.7. I did test the problem with 5.9 and current, and both fail. Here is my configuration: --- ifconfig lo0: flags=8049 mtu 32768 priority: 0 groups: lo inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 inet 127.0.0.1 netmask 0xff00 vio0: flags=8843 mtu 1500 lladdr 52:54:00:9e:b2:2b priority: 0 media: Ethernet autoselect status: active inet 10.0.1.2 netmask 0x broadcast 10.0.255.255 vio1: flags=8843 mtu 1500 lladdr 52:54:00:fd:df:4c priority: 0 media: Ethernet autoselect status: active inet 192.168.0.11 netmask 0xff00 broadcast 192.168.0.255 vio2: flags=8843 mtu 1500 lladdr 52:54:00:d0:e8:1d priority: 0 groups: egress media: Ethernet autoselect status: active inet 192.168.0.12 netmask 0xff00 broadcast 192.168.0.255 --- route -n show Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface default192.168.0.1UGS0 46 - 8 vio2 10.0/1610.0.1.2 UC 3 26 - 4 vio0 10.0.0.1 00:00:5e:00:01:01 UHLc 0 59 - 4 vio0 10.0.1.2 52:54:00:9e:b2:2b UHLl 0 34 - 1 vio0 10.0.1.15 52:54:00:0e:62:c7 UHLc 0 16 - 4 vio0 10.0.3.10 ac:87:a3:1d:3f:9d UHLc 1 16 - 4 vio0 10.0.255.255 10.0.1.2 UHb00 - 1 vio0 127.0.0.1 127.0.0.1 UHl0 192 32768 1 lo0 192.168.0/24 192.168.0.11 UCP17 - 4 vio1 192.168.0/24 192.168.0.12 UCP00 - 4 vio2 192.168.0.1link#2 UHLc 0 25 - 4 vio1 192.168.0.11 52:54:00:fd:df:4c UHLl 0 16 - 1 vio1 192.168.0.12 52:54:00:d0:e8:1d UHLl 03 - 1 vio2 192.168.0.255 192.168.0.11 UHPb 00 - 1 vio1 192.168.0.255 192.168.0.12 UHPb 00 - 1 vio2 Internet6: DestinationGatewayFlags Refs Use Mtu Prio Iface ::1::1UHl0 0 32768 1 lo0 fe80::1%lo0fe80::1%lo0UHl0 0 32768 1 lo0 ff01::%lo0/32 ::1UC 0 1 32768 4 lo0 ff02::%lo0/32 ::1UC 0 1 32768 4 lo0 -- ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes ping: sendto: No route to host ping: wrote 8.8.8.8 64 chars, ret=-1 ping: sendto: No route to host ping: wrote 8.8.8.8 64 chars, ret=-1 --- 8.8.8.8 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss [1]81614 exit 1 ping 8.8.8.8 If I change the default route to vio1, it works. The problem occurs only when the default route is on the second interface (vio2, or carp0 in my cases). Can someone confirm this is a bug in the routing system ? Regards Jean-Daniel.
Re: IPV6 routing issue
Em 25-07-2015 11:50, Stuart Henderson escreveu: > Actually that's fine, a point-to-point interface can be unnumbered, > or in the case of IPv6, it can just have a link-local address. In my case I don't have a ppp interface, my CPE talks to my OpenBSD firewall through normal LAN. > DHCPv6 PD would give you a /64 or (if allowed by the ISP) a larger > prefix to assign to interfaces as you choose. Normally you would > assign this to "internal" interface/s, but assuming the ISP allows > more than a /64, you *can* apply part of that delegation to the > PPP interface if you would like it to have a globally routable > address. This is one of my problems, my ISP would only give me a /64 prefix, not a /56 or other manageable size. I can ask a PD from the CPE, but the only prefix already is delegated to the CPE itself. So the CPE keeps asking me neighbor solicitation messages, and won't route the packets. Unless I use NDP proxying, I can't do normal routing. As I stated, I did a bridge. When I have some free time I'll visit the NDP proxy again. Perhaps I'll be able to port some of the existing solutions to OpenBSD. Cheers, Giancarlo Razzolini
Re: IPV6 routing issue
On 2015-06-26, Christian Weisgerber wrote: > On 2015-06-26, Giancarlo Razzolini wrote: > >> I've recently changed my ISP and they have native IPv6. My customer >> premises equipment, which is a GPON, supports both stateless as DHCPv6 >> on it's LAN interface. I want to put a OpenBSD firewall between this CPE >> and my internal network. > > So you have TWO networks. One between the CPE and your OpenBSD > firewall, and one containing the firewall and your internal machines. > >> I'm using OpenBSD 5.7 stable. My CPE receive a >> /64 prefix delegation from my ISP. > > So you get ONE network address. > > You can't use a single network address for two networks. This has > nothing to do with IPv6. It's the same with IPv4. Actually that's fine, a point-to-point interface can be unnumbered, or in the case of IPv6, it can just have a link-local address. So PPP can *only* configure a link-local address. To get a globally routable address you must use another method, either SLAAC, DHCPv6 PD, or static configuration. SLAAC would only give you an address on a /64 for use on the PPP interface itself. DHCPv6 PD would give you a /64 or (if allowed by the ISP) a larger prefix to assign to interfaces as you choose. Normally you would assign this to "internal" interface/s, but assuming the ISP allows more than a /64, you *can* apply part of that delegation to the PPP interface if you would like it to have a globally routable address.
Re: IPV6 routing issue
Em 26-06-2015 16:44, Christian Weisgerber escreveu: Well, you can add an IPv6 address for each internal host to the external interface of your firewall, use private addresses on the internal network, and then use pf's binat to map between the two. This will preserve port numbers, although it may not be enough for nasty protocols like SIP. I know I could use NAT. But, I really think it's almost an abomination to use it, when you have native IPv6 support. I'll contact my ISP to see if they can change my CPE mode of operation or, at least, allow me to configure it. In the meantime, I'll go with a bridge firewall. It seems like the most hassle free way to go. Perhaps I'll hack some NDP proxy. But I need IPv6 connectivity, and I need it now. Cheers, Giancarlo Razzolini
Re: IPV6 routing issue
On 2015-06-26, Giancarlo Razzolini wrote: > I don't know if OpenBSD does have any NDP proxying functionality, > besides the one in ndp(8). But it seems to me that, besides a bridge, a > NDP proxy is the only viable solution (besides my ISP allowing me to > change my router configuration). Well, you can add an IPv6 address for each internal host to the external interface of your firewall, use private addresses on the internal network, and then use pf's binat to map between the two. This will preserve port numbers, although it may not be enough for nasty protocols like SIP. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: IPV6 routing issue
Em 26-06-2015 16:17, Christian Weisgerber escreveu: So you have TWO networks. One between the CPE and your OpenBSD firewall, and one containing the firewall and your internal machines. Yes. Two interfaces, to be more exactly. So you get ONE network address. I get a prefix on the CPE. And I can configure any address in the prefix on any machine on my LAN (or the OpenBSD LAN iface). And traffic gets out. Just won't get replies. You can't use a single network address for two networks. This has nothing to do with IPv6. It's the same with IPv4. I'm aware of that fact. But, since my CPE replies to an IA_PD request, I imagined it would be able to route the packets correctly. You can use private addresses for your internal network and run NAT on the firewall. Or you can configure your firewall as a bridge and filter there. http://www.openbsd.org/faq/faq6.html#Bridge I'm trying to get some NDP proxy running on OpenBSD. But all of them are linux centric. Perhaps, for now, I will use it as a filtering bridge. Since I have enough interfaces on my OpenBSD machine, I will have a bridge specifically for IPv6. And IPv4 will still be NATed. Cheers, Giancarlo Razzolini
Re: IPV6 routing issue
On 2015-06-26, Giancarlo Razzolini wrote: > I've recently changed my ISP and they have native IPv6. My customer > premises equipment, which is a GPON, supports both stateless as DHCPv6 > on it's LAN interface. I want to put a OpenBSD firewall between this CPE > and my internal network. So you have TWO networks. One between the CPE and your OpenBSD firewall, and one containing the firewall and your internal machines. > I'm using OpenBSD 5.7 stable. My CPE receive a > /64 prefix delegation from my ISP. So you get ONE network address. You can't use a single network address for two networks. This has nothing to do with IPv6. It's the same with IPv4. You can use private addresses for your internal network and run NAT on the firewall. Or you can configure your firewall as a bridge and filter there. http://www.openbsd.org/faq/faq6.html#Bridge -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: IPV6 routing issue
Em 26-06-2015 10:43, Gregor Best escreveu: https://github.com/DanielAdolfsson/ndppd This doesn't compile on OpenBSD. I'm correcting it's includes and headers, but it seems it's linux centric. I'll probably need to change it's code. I've found some other tools but it seems almost all of them are linux centric: [0]: https://github.com/fishilico/autoneighxy [1]: https://github.com/andriyanov/ndp-proxy I don't know if OpenBSD does have any NDP proxying functionality, besides the one in ndp(8). But it seems to me that, besides a bridge, a NDP proxy is the only viable solution (besides my ISP allowing me to change my router configuration). Cheers, Giancarlo Razzolini
Re: IPV6 routing issue
Em 26-06-2015 10:43, Gregor Best escreveu: I've also seen something similar. A friend of mine suggested [0], though I haven't tried it. I circumvented my problem by using a routed /64 on a Hurricane Electric tunnel. I wouldn't like to use a tunnel, since my ISP is (kind of) providing native IPv6 connectivity. Depending on your hosting provider, their setup might actually be vulnerable to a neat little trick: If you see NDP requests for prefixes that are not your own while tcpdump'ing your external interface, you might be able to add an address inside one of those networks to your external interface and have it reachable from the outside, so that in effect you can use an IPv6 address that's outside of your prefix. Since my CPE is working in routed mode, I don't see anything like that. But, I believe that this will be a problem for many ISP's, since I doubt they will implement authenticated NDP. I will look into this ndp proxy daemon, since I couldn't make the ndp(8) proxy functionality to work. Thank all you guys who replied. Both on and off list. Cheers, Giancarlo Razzolini
Re: IPV6 routing issue
Em 26-06-2015 10:07, Patrik Lundin escreveu: I have struggled with a similar problem a few years back. Can it be that the upstream equipment does not create a route for the delegated prefix pointing to your openbsd machine? This would explain why you see neighbour solicitations on the outside interface. The upstream router is not aware that the prefix should be routed to you. Yes, I believe it to be te problem. The prefix is delegated to the CPE, not the OpenBSD machine. When I run the dhcp6c program, it asks for a prefix delegation from the CPE and gets one. But I don't think that the CPE is trully delegating the prefix, hence that's why he's issuing neighbor solicitation messages. Someone pointed to me that I'll need to use a ndp proxy or use the openbsd machine as a bridge filter. I can't change the CPE configuration, it's locked by my ISP. Cheers, Giancarlo Razzolini
Re: IPV6 routing issue
On Fri, Jun 26, 2015 at 03:07:41PM +0200, Patrik Lundin wrote: > [...] > This would explain why you see neighbour solicitations on the outside > interface. The upstream router is not aware that the prefix should be > routed to you. > [...] I've also seen something similar. A friend of mine suggested [0], though I haven't tried it. I circumvented my problem by using a routed /64 on a Hurricane Electric tunnel. Depending on your hosting provider, their setup might actually be vulnerable to a neat little trick: If you see NDP requests for prefixes that are not your own while tcpdump'ing your external interface, you might be able to add an address inside one of those networks to your external interface and have it reachable from the outside, so that in effect you can use an IPv6 address that's outside of your prefix. [0]: https://github.com/DanielAdolfsson/ndppd -- Gregor Best
Re: IPV6 routing issue
I have struggled with a similar problem a few years back. Can it be that the upstream equipment does not create a route for the delegated prefix pointing to your openbsd machine? This would explain why you see neighbour solicitations on the outside interface. The upstream router is not aware that the prefix should be routed to you. -- Patrik Lundin - Original message - From: Giancarlo Razzolini To: "Openbsd-Misc" Subject: IPV6 routing issue Date: Thu, 25 Jun 2015 21:06:51 -0300 HI all, I've recently changed my ISP and they have native IPv6. My customer premises equipment, which is a GPON, supports both stateless as DHCPv6 on it's LAN interface. I want to put a OpenBSD firewall between this CPE and my internal network. I'm using OpenBSD 5.7 stable. My CPE receive a /64 prefix delegation from my ISP. Unfortunately, this is a dynamic prefix, so I can't configure anything manually. I've managed to get wide-dhcp6 working and requesting the prefix to be delegated to my internal network. After that, all I needed to do was to run rtadvd on my internal interface, and my internal LAN machines began to be autoconfigurated getting ip's from the delegated prefix. The OpenBSD firewall has 2 ipv6 addresses. One on the WAN interface and another on the LAN interface. If I use ping6 to ping any ipv6 host from my firewall, I can ping them with no problems. But, If I ping setting the source to be the ipv6 address from the internal interface, it won't work. Also, no machine from my LAN can connect to any host through ipv6. I've inspected the traffic with tcpdump, and I can see the packets leaving my network and getting on the destination. The problem is the packets never gets back. My CPE equipment keeps asking for neighbour solicitation asking who has the ipv6 address, but the OpenBSD firewall never replies, so the packts get dropped. I'm currently with PF disabled. But I had the same problem with it enabled and with the default firewall configuration. I'm trying first to get ipv6 connectivity working to after filter the packets. Anyone had a similar issue? Cheers, Giancarlo Razzolini
IPV6 routing issue
HI all, I've recently changed my ISP and they have native IPv6. My customer premises equipment, which is a GPON, supports both stateless as DHCPv6 on it's LAN interface. I want to put a OpenBSD firewall between this CPE and my internal network. I'm using OpenBSD 5.7 stable. My CPE receive a /64 prefix delegation from my ISP. Unfortunately, this is a dynamic prefix, so I can't configure anything manually. I've managed to get wide-dhcp6 working and requesting the prefix to be delegated to my internal network. After that, all I needed to do was to run rtadvd on my internal interface, and my internal LAN machines began to be autoconfigurated getting ip's from the delegated prefix. The OpenBSD firewall has 2 ipv6 addresses. One on the WAN interface and another on the LAN interface. If I use ping6 to ping any ipv6 host from my firewall, I can ping them with no problems. But, If I ping setting the source to be the ipv6 address from the internal interface, it won't work. Also, no machine from my LAN can connect to any host through ipv6. I've inspected the traffic with tcpdump, and I can see the packets leaving my network and getting on the destination. The problem is the packets never gets back. My CPE equipment keeps asking for neighbour solicitation asking who has the ipv6 address, but the OpenBSD firewall never replies, so the packts get dropped. I'm currently with PF disabled. But I had the same problem with it enabled and with the default firewall configuration. I'm trying first to get ipv6 connectivity working to after filter the packets. Anyone had a similar issue? Cheers, Giancarlo Razzolini
Re: Local routing issue when iked running
On Fri, Feb 28, 2014 at 9:52 AM, Stuart Henderson wrote: > > I'm sure it's a bug, I suspect possibly in some dark corner of radix.c. > I haven't heard of anybody else hitting this same problem so in a way > I'm quite glad it's not just me :) > > On box1 you have these flows > > 192.168.150.13/32 0 192.168.150.16/32 0 0 192.168.150.13/esp/use/in > 192.168.150.16/32 0 192.168.150.13/32 0 0 > 192.168.150.13/esp/require/out > > which ought to only match "proto esp" traffic between 192.168.150.13 and > 192.168.150.16, but it actually matches "proto tcp port 22" traffic > between 192.168.150.16 and itself (192.168.150.16). > > This is at least a potentially useful extra data point that it happens > with iked as well as manual keying. > > The common factor between your case and mine is that the flow which is > attracting traffic which it shouldn't, uses "proto esp". > Yep, agreed. I was not sure to understand why TCP port 22 is "sucked" into that rule. It shouldn't as you say. > Workaround, well, it only seems to affect the local address in the > flow (i.e. in your case 192.168.150.16) so if you have another locally > configured address that you can change the flow to use, you might be able > to get around it...not nice though. > It also actually affects "real" public IP addresses. Before sending this first email, I had the same problem on 2 OpenBSD boxes 5.4-release (GENERIC.MP i386) with each a public static IP address. Both are linked through ikev2 / IPsec with the same rulesets as above (modulo the IP addresses of course). Each box runs SSH and NSD. While there is no issue to reach the box on port 22 and 53 from the outside when the VPN is up, it is not possible to access the service on the box itself (I tried with PF enabled, disabled and basically using the same procedure as my first email and conclude to the same result: impossible to reach locally the service when the VPN is up; the traffic is sent to enc0 and tcpdump produces the same output on enc0 (again modulo the IP addresses)) I thought something was wrong with my setup so tried to reproduce the problem on a local subnet (192.168/16) and managed to. Using another extra public address on each box is not really an option nor creating a vether interface on each box as I was intentionally creating a "site to site" VPN on purpose. I am kind of stuck. Will try to look at radix.c but if you have any additional pointers or tips, that would be greatly appreciated.. In a way, I am also glad to hear you are facing some similar issue :) Cheers, Josh
Re: Local routing issue when iked running
On 2014-02-27, Josh wrote: > On Thu, Feb 27, 2014 at 11:00 AM, Stuart Henderson > wrote: >> >> Try tcpdumping packets going over the ipsec tunnel, do you see those packets >> which should be local actually being sent over the tunnel? If so, I don't >> have >> an answer for this, but I've seen it myself, though only with manually >> configured ipsec rather than IKE (though I've only really tried IKEv1 with >> isakmpd, not IKEv2). I've mentioned it to a few people but haven't heard any >> possible explanations yet. >> > > Hi Stuart, > > It seems to be what I am facing: (tcpdump output on box1 when > performing a telnet box1_ip (192.168.150.16) to port 22 on box1) > box1:~# tcpdump -envps 1500 -i enc0 -l > tcpdump: listening on enc0, link-type ENC > 11:18:15.258255 (authentic,confidential): SPI 0xf704e810: > 192.168.150.13 > 192.168.150.16: 192.168.150.16.33636 > > 192.168.150.16.22: S [tcp sum ok] 724448283:724448283(0) win 16384 > > (DF) [tos 0x10] (ttl 64, id 47660, len 64) (DF) [tos 0x10] (ttl 64, id > 59798, len 84, bad cksum 0!) > 11:18:15.258422 (authentic,confidential): SPI 0xf704e810: > 192.168.150.13 > 192.168.150.16: 192.168.150.16.33636 > > 192.168.150.16.22: S [tcp sum ok] 724448283:724448283(0) win 16384 > > (DF) [tos 0x10] (ttl 64, id 47660, len 64) (DF) [tos 0x10] (ttl 64, id > 59798, len 84) > > Is that a bug or just normal behavior and is there any way to get around it? > > Cheers, > Josh > > I'm sure it's a bug, I suspect possibly in some dark corner of radix.c. I haven't heard of anybody else hitting this same problem so in a way I'm quite glad it's not just me :) On box1 you have these flows 192.168.150.13/32 0 192.168.150.16/32 0 0 192.168.150.13/esp/use/in 192.168.150.16/32 0 192.168.150.13/32 0 0 192.168.150.13/esp/require/out which ought to only match "proto esp" traffic between 192.168.150.13 and 192.168.150.16, but it actually matches "proto tcp port 22" traffic between 192.168.150.16 and itself (192.168.150.16). This is at least a potentially useful extra data point that it happens with iked as well as manual keying. The common factor between your case and mine is that the flow which is attracting traffic which it shouldn't, uses "proto esp". Workaround, well, it only seems to affect the local address in the flow (i.e. in your case 192.168.150.16) so if you have another locally configured address that you can change the flow to use, you might be able to get around it...not nice though.
Re: Local routing issue when iked running
On Thu, Feb 27, 2014 at 11:00 AM, Stuart Henderson wrote: > > Try tcpdumping packets going over the ipsec tunnel, do you see those packets > which should be local actually being sent over the tunnel? If so, I don't have > an answer for this, but I've seen it myself, though only with manually > configured ipsec rather than IKE (though I've only really tried IKEv1 with > isakmpd, not IKEv2). I've mentioned it to a few people but haven't heard any > possible explanations yet. > Hi Stuart, It seems to be what I am facing: (tcpdump output on box1 when performing a telnet box1_ip (192.168.150.16) to port 22 on box1) box1:~# tcpdump -envps 1500 -i enc0 -l tcpdump: listening on enc0, link-type ENC 11:18:15.258255 (authentic,confidential): SPI 0xf704e810: 192.168.150.13 > 192.168.150.16: 192.168.150.16.33636 > 192.168.150.16.22: S [tcp sum ok] 724448283:724448283(0) win 16384 (DF) [tos 0x10] (ttl 64, id 47660, len 64) (DF) [tos 0x10] (ttl 64, id 59798, len 84, bad cksum 0!) 11:18:15.258422 (authentic,confidential): SPI 0xf704e810: 192.168.150.13 > 192.168.150.16: 192.168.150.16.33636 > 192.168.150.16.22: S [tcp sum ok] 724448283:724448283(0) win 16384 (DF) [tos 0x10] (ttl 64, id 47660, len 64) (DF) [tos 0x10] (ttl 64, id 59798, len 84) Is that a bug or just normal behavior and is there any way to get around it? Cheers, Josh
Re: Local routing issue when iked running
On 2014-02-26, Josh wrote: > Hi @misc, > > I am facing an issue between two boxes (box1 and box2) connected > through an IPsec tunnel. > They are both on the same subnet and both listen on port 22 (sshd running) > > When the ipsec tunnel is down and encap routes are flushed on both > boxes (ipsecctl -F), performing a "telnet ip_of_box1 22" on box1 works > fine. Same on box2. > However, when the ipsec tunnel is up, performing the same telnet > command on box1 will just time out. Same timeout on box2. Reaching > box1 from box2 and vice versa is not a problem. > > I am not sure to understand why I can't reach the local IP address > when the tunnel is up. Try tcpdumping packets going over the ipsec tunnel, do you see those packets which should be local actually being sent over the tunnel? If so, I don't have an answer for this, but I've seen it myself, though only with manually configured ipsec rather than IKE (though I've only really tried IKEv1 with isakmpd, not IKEv2). I've mentioned it to a few people but haven't heard any possible explanations yet.
Local routing issue when iked running
Hi @misc, I am facing an issue between two boxes (box1 and box2) connected through an IPsec tunnel. They are both on the same subnet and both listen on port 22 (sshd running) When the ipsec tunnel is down and encap routes are flushed on both boxes (ipsecctl -F), performing a "telnet ip_of_box1 22" on box1 works fine. Same on box2. However, when the ipsec tunnel is up, performing the same telnet command on box1 will just time out. Same timeout on box2. Reaching box1 from box2 and vice versa is not a problem. I am not sure to understand why I can't reach the local IP address when the tunnel is up. Any hint would be much appreciated, Below some config / output (both are running 5.5 current i386 GENERIC.MP but I did reproduce the "problem" with exactly the same config on 5.4 release GENERIC.MP i386 on both boxes) and the two last commands showing the time out when performing the telnet. Cheers, Josh box1:~# cat /etc/hostname.em0 dhcp box2:~# cat /etc/hostname.em0 dhcp box1:~# ifconfig em0 em0: flags=8843 mtu 1500 lladdr 08:00:27:db:76:6f priority: 0 groups: egress media: Ethernet autoselect (1000baseT full-duplex) status: active inet6 fe80::a00:27ff:fedb:766f%em0 prefixlen 64 scopeid 0x1 inet 192.168.150.16 netmask 0xff00 broadcast 192.168.150.255 box2:~# ifconfig em0 em0: flags=8843 mtu 1500 lladdr 08:00:27:a3:85:3a priority: 0 groups: egress media: Ethernet autoselect (1000baseT full-duplex) status: active inet6 fe80::a00:27ff:fea3:853a%em0 prefixlen 64 scopeid 0x1 inet 192.168.150.13 netmask 0xff00 broadcast 192.168.150.255 box1:~# pfctl -d pfctl: pf not enabled box2:~# pfctl -d pfctl: pf not enabled box1:~# netstat -nr Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface default192.168.150.254UGS4 843047 - 8 em0 127/8 127.0.0.1 UGRS 00 33192 8 lo0 127.0.0.1 127.0.0.1 UH 1 33 33192 4 lo0 192.168.150/24 link#1 UC 30 - 4 em0 192.168.150.1 10:dd:b1:99:a0:d7 UHLc 142048 - 4 em0 192.168.150.13 08:00:27:a3:85:3a UHLc 0 14 - 4 em0 192.168.150.25400:00:24:ce:84:bc UHLc 1 393 - 4 em0 224/4 127.0.0.1 URS00 33192 8 lo0 box2:~# netstat -nr Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface default192.168.150.254UGS4 909362 - 8 em0 127/8 127.0.0.1 UGRS 00 33192 8 lo0 127.0.0.1 127.0.0.1 UH 1 115 33192 4 lo0 192.168.150/24 link#1 UC 30 - 4 em0 192.168.150.13 08:00:27:a3:85:3a UHLc 0 18 - 4 lo0 192.168.150.16 08:00:27:db:76:6f UHLc 0 22 - 4 em0 192.168.150.25400:00:24:ce:84:bc UHLc 1 1005 - 4 em0 224/4 127.0.0.1 URS00 33192 8 lo0 box1:~# cat /etc/iked.conf ikev2 passive esp from 192.168.150.16 to 192.168.150.13 peer 192.168.150.13 psk "tesT" box2:~# cat /etc/iked.conf ikev2 active esp from 192.168.150.13 to 192.168.150.16 peer 192.168.150.16 psk "tesT" box1:~# ipsecctl -sa FLOWS: No flows SAD: No entries box2:~# ipsecctl -sa FLOWS: No flows SAD: No entries box1:~# telnet 192.168.150.16 22 Trying 192.168.150.16... Connected to 192.168.150.16. Escape character is '^]'. SSH-2.0-OpenSSH_6.5 ^C Connection closed by foreign host. box2:~# telnet 192.168.150.13 22 Trying 192.168.150.13... Connected to 192.168.150.13. Escape character is '^]'. SSH-2.0-OpenSSH_6.5 ^C Connection closed by foreign host. box1:~# iked -6dv ikev2 "policy1" passive esp inet from 192.168.150.16 to 192.168.150.13 local any peer 192.168.150.13 ikesa enc aes-256,aes-192,aes-128,3des prf hmac-sha2-256,hmac-sha1,hmac-md5 auth hmac-sha2-256,hmac-sha1,hmac-md5 group modp2048-256,modp2048,modp1536,modp1024 childsa enc aes-256,aes-192,aes-128 auth hmac-sha2-256,hmac-sha1 lifetime 10800 bytes 536870912 psk 0x74657354 ikev2_recv: IKE_SA_INIT from initiator 192.168.150.13:500 to 192.168.150.16:500 policy 'policy1' id 0, 520 bytes ikev2_msg_send: IKE_SA_INIT from 192.168.150.16:500 to 192.168.150.13:500, 432 bytes ikev2_recv: IKE_AUTH from initiator 192.168.150.13:500 to 192.168.150.16:500 policy 'policy1' id 1, 272 bytes ikev2_msg_send: IKE_AUTH from 192.168.150.16:500 to 192.168.150.13:500, 240 bytes sa_state: VALID -> ESTABLISHED from 192.168.150.13:500 to 192.168.150.16:500 policy 'policy1' box2:~# iked -6dv ikev2 "policy1" active esp inet from 192.168.150.13 to 192.168.150.16 local any peer 192.168.150.16 ikesa enc aes-256,aes-192,aes-128,3des prf hmac-sha2-256,hmac-sha1,hmac-md5 auth
Re: Routing Issue
For what its worth: I have setup an exact same Machine at Home, same Network Topology etc, and it works just fine. What is different at work is that we have a switch in between that also routing, i assume the problem lies there. regards and a nice day, D On May 18, 2011, at 10:18 PM, David Schulz wrote: > Well for once i thought the Route is listed there already: > > Default Gateway: >> default10.1.3.1 UGS03 - 8 > sis0 > > And everything to the 192. Subnet out via sis1 >> 192.168.1/24 link#2 UC 10 - 4 > sis1 > > > > So i have to add something else? One Side of the Network is 10.1.0.0/21 with > Gateway 10.1.3.1, so i add >route add -net 10.1.0.0/21 10.1.3.1 > > The other Side, for which the OpenBSD Box is the Gateway is 192.168.1.0/24, so > i suppose i add > route add -net 192.168.1.0/24 192.168.1.1 ? > > Thanks for your insights. > > > On May 18, 2011, at 10:06 PM, R0me0 *** wrote: > >> Put a route !? >> >> 2011/5/18 David Schulz >> Hi there, >> >> if i disable pf, it will not work (except when trying from router itself > via >> ssh). Here some output from hostname.ifs and mygate, my routing table. > Would >> be most grateful for any tips that help solving this. >> >> Best regards, >> D >> >> cndlne001'root(~)> cat /etc/hostname.sis0 >> inet 10.1.3.19 255.255.254.0 NONE >> cndlne001'root(~)> cat /etc/hostname.sis1 >> inet 192.168.1.1 255.255.255.0 NONE >> cndlne001'root(~)> cat /etc/mygate >> 10.1.3.1 >> cndlne001'root(~)> route -n show >> Routing tables >> >> Internet: >> DestinationGatewayFlags Refs Use Mtu Prio > Iface >> default10.1.3.1 UGS03 - 8 > sis0 >> 10.1.2/23 link#1 UC 40 - 4 > sis0 >> 10.1.3.1 00:18:4d:33:e3:df UHLc 10 - 4 > sis0 >> 10.1.3.7 f4:ce:46:b1:a6:26 UHLc 1 10 - 4 > sis0 >> 10.1.3.37 20:cf:30:56:15:80 UHLc 1 107 - 4 > sis0 >> 10.1.3.46 1c:af:f7:0e:17:20 UHLc 0 41 - 4 > sis0 >> 127/8 127.0.0.1 UGRS 00 33200 8 lo0 >> 127.0.0.1 127.0.0.1 UH 10 33200 4 lo0 >> > >> 192.168.1.200:14:97:02:2b:b2 UHLc 0 41 - 4 > sis1 >> 224/4 127.0.0.1 URS00 33200 8 lo0 >> >> cndlne001'root(~)> sysctl net.inet.ip.forwarding >> net.inet.ip.forwarding=1 >> >> sis0: flags=8843 mtu 1500 >> lladdr 00:00:24:ca:a9:f4 >> priority: 0 >> groups: egress >> media: Ethernet autoselect (100baseTX full-duplex) >> status: active >> inet 10.1.3.19 netmask 0xfe00 broadcast 10.1.3.255 >> inet6 fe80::200:24ff:feca:a9f4%sis0 prefixlen 64 scopeid 0x1 >> cndlne001'root(~)> ifconfig sis1 >> sis1: flags=8843 mtu 1500 >> lladdr 00:00:24:ca:a9:f5 >> priority: 0 >> media: Ethernet autoselect (100baseTX full-duplex) >> status: active >> inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 >> inet6 fe80::200:24ff:feca:a9f5%sis1 prefixlen 64 scopeid 0x2 >> cndlne001'root(~)> >> >> >> On May 18, 2011, at 2:29 PM, Aaron Mason wrote: >> >>> If you've disabled pf and it doesn't, then yes, possibly. >>> >>> If the network is configured like this: >>> >>> 192.168.1.0/24]192.168.1.1(em0)[Router]10.1.0.1(em1)[10.1.0.0/21 >>> >>> Setting the default routes to the required interface on each side >>> should allow packets to flow freely from end to end. There should be >>> no need for PF trickery unless you wish to restrict access to certain >>> machines on either side. >>> >>> Your best test is a traceroute. Perform a traceroute from one side to >>> the other, and see what the last step is before you get a string of >>> timeouts. >>> >>> All said, I see rules in your PF that allow certain ICMP types, but >>> haven't included the echo response - that's probably why you can't >>> ping across the router. >>> >>> On Wed, May 18, 2011 at 3:29 PM, David Schulz >>> wrote: >>>> Basically i am just trying to verify whether i actually d
Re: Routing Issue
Well for once i thought the Route is listed there already: Default Gateway: > default10.1.3.1 UGS03 - 8 sis0 And everything to the 192. Subnet out via sis1 > 192.168.1/24 link#2 UC 10 - 4 sis1 So i have to add something else? One Side of the Network is 10.1.0.0/21 with Gateway 10.1.3.1, so i add route add -net 10.1.0.0/21 10.1.3.1 The other Side, for which the OpenBSD Box is the Gateway is 192.168.1.0/24, so i suppose i add route add -net 192.168.1.0/24 192.168.1.1 ? Thanks for your insights. On May 18, 2011, at 10:06 PM, R0me0 *** wrote: > Put a route !? > > 2011/5/18 David Schulz > Hi there, > > if i disable pf, it will not work (except when trying from router itself via > ssh). Here some output from hostname.ifs and mygate, my routing table. Would > be most grateful for any tips that help solving this. > > Best regards, > D > > cndlne001'root(~)> cat /etc/hostname.sis0 > inet 10.1.3.19 255.255.254.0 NONE > cndlne001'root(~)> cat /etc/hostname.sis1 > inet 192.168.1.1 255.255.255.0 NONE > cndlne001'root(~)> cat /etc/mygate > 10.1.3.1 > cndlne001'root(~)> route -n show > Routing tables > > Internet: > DestinationGatewayFlags Refs Use Mtu Prio Iface > default10.1.3.1 UGS03 - 8 sis0 > 10.1.2/23 link#1 UC 40 - 4 sis0 > 10.1.3.1 00:18:4d:33:e3:df UHLc 10 - 4 sis0 > 10.1.3.7 f4:ce:46:b1:a6:26 UHLc 1 10 - 4 sis0 > 10.1.3.37 20:cf:30:56:15:80 UHLc 1 107 - 4 sis0 > 10.1.3.46 1c:af:f7:0e:17:20 UHLc 0 41 - 4 sis0 > 127/8 127.0.0.1 UGRS 00 33200 8 lo0 > 127.0.0.1 127.0.0.1 UH 10 33200 4 lo0 > > 192.168.1.200:14:97:02:2b:b2 UHLc 0 41 - 4 sis1 > 224/4 127.0.0.1 URS00 33200 8 lo0 > > cndlne001'root(~)> sysctl net.inet.ip.forwarding > net.inet.ip.forwarding=1 > > sis0: flags=8843 mtu 1500 >lladdr 00:00:24:ca:a9:f4 >priority: 0 >groups: egress >media: Ethernet autoselect (100baseTX full-duplex) >status: active >inet 10.1.3.19 netmask 0xfe00 broadcast 10.1.3.255 >inet6 fe80::200:24ff:feca:a9f4%sis0 prefixlen 64 scopeid 0x1 > cndlne001'root(~)> ifconfig sis1 > sis1: flags=8843 mtu 1500 >lladdr 00:00:24:ca:a9:f5 >priority: 0 >media: Ethernet autoselect (100baseTX full-duplex) >status: active >inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 >inet6 fe80::200:24ff:feca:a9f5%sis1 prefixlen 64 scopeid 0x2 > cndlne001'root(~)> > > > On May 18, 2011, at 2:29 PM, Aaron Mason wrote: > > > If you've disabled pf and it doesn't, then yes, possibly. > > > > If the network is configured like this: > > > > 192.168.1.0/24]192.168.1.1(em0)[Router]10.1.0.1(em1)[10.1.0.0/21 > > > > Setting the default routes to the required interface on each side > > should allow packets to flow freely from end to end. There should be > > no need for PF trickery unless you wish to restrict access to certain > > machines on either side. > > > > Your best test is a traceroute. Perform a traceroute from one side to > > the other, and see what the last step is before you get a string of > > timeouts. > > > > All said, I see rules in your PF that allow certain ICMP types, but > > haven't included the echo response - that's probably why you can't > > ping across the router. > > > > On Wed, May 18, 2011 at 3:29 PM, David Schulz > > wrote: > >> Basically i am just trying to verify whether i actually do need the match > > out > >> statements in pf.conf in order for both Sides on each Network Cards to > talk > > to > >> each other. Say i do not, and it should all just work, does the fact that > > it > >> does not work suggest that i most likely have a routing issue? > >> > >> best regards, > >> D > >> > >> On May 17, 2011, at 9:29 PM, David Gwynne wrote: > >> > >>> hey david, > >>> > >>> pf is run twice on packets going through a box, once before the network > >> stack > >>> and again as it leaves it. this means you have to allow a packet in one > >> side > >>> as well
Re: Routing Issue
Have you tried doing the following: sysctl net.inet.ip.forwarding=1 This effectively turns OpenBSD into a router. If you also need to handle, IPV6 traffic: syscttl net.inet6.ip6.forwarding=1 To make this consistent across reboots, edit the sysctl.conf file. Hi there, if i disable pf, it will not work (except when trying from router itself via ssh). Here some output from hostname.ifs and mygate, my routing table. Would be most grateful for any tips that help solving this. Best regards, D cndlne001'root(~)> cat /etc/hostname.sis0 inet 10.1.3.19 255.255.254.0 NONE cndlne001'root(~)> cat /etc/hostname.sis1 inet 192.168.1.1 255.255.255.0 NONE cndlne001'root(~)> cat /etc/mygate 10.1.3.1 cndlne001'root(~)> route -n show Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface default10.1.3.1 UGS03 - 8 sis0 10.1.2/23 link#1 UC 40 - 4 sis0 10.1.3.1 00:18:4d:33:e3:df UHLc 10 - 4 sis0 10.1.3.7 f4:ce:46:b1:a6:26 UHLc 1 10 - 4 sis0 10.1.3.37 20:cf:30:56:15:80 UHLc 1 107 - 4 sis0 10.1.3.46 1c:af:f7:0e:17:20 UHLc 0 41 - 4 sis0 127/8 127.0.0.1 UGRS 00 33200 8 lo0 127.0.0.1 127.0.0.1 UH 10 33200 4 lo0 192.168.1/24 link#2 UC 10 - 4 sis1 192.168.1.200:14:97:02:2b:b2 UHLc 0 41 - 4 sis1 224/4 127.0.0.1 URS00 33200 8 lo0 cndlne001'root(~)> sysctl net.inet.ip.forwarding net.inet.ip.forwarding=1 sis0: flags=8843 mtu 1500 lladdr 00:00:24:ca:a9:f4 priority: 0 groups: egress media: Ethernet autoselect (100baseTX full-duplex) status: active inet 10.1.3.19 netmask 0xfe00 broadcast 10.1.3.255 inet6 fe80::200:24ff:feca:a9f4%sis0 prefixlen 64 scopeid 0x1 cndlne001'root(~)> ifconfig sis1 sis1: flags=8843 mtu 1500 lladdr 00:00:24:ca:a9:f5 priority: 0 media: Ethernet autoselect (100baseTX full-duplex) status: active inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 inet6 fe80::200:24ff:feca:a9f5%sis1 prefixlen 64 scopeid 0x2 cndlne001'root(~)> On May 18, 2011, at 2:29 PM, Aaron Mason wrote: > If you've disabled pf and it doesn't, then yes, possibly. > > If the network is configured like this: > > 192.168.1.0/24]192.168.1.1(em0)[Router]10.1.0.1(em1)[10.1.0.0/21 > > Setting the default routes to the required interface on each side > should allow packets to flow freely from end to end. There should be > no need for PF trickery unless you wish to restrict access to certain > machines on either side. > > Your best test is a traceroute. Perform a traceroute from one side to > the other, and see what the last step is before you get a string of > timeouts. > > All said, I see rules in your PF that allow certain ICMP types, but > haven't included the echo response - that's probably why you can't > ping across the router. > > On Wed, May 18, 2011 at 3:29 PM, David Schulz > wrote: >> Basically i am just trying to verify whether i actually do need the match > out >> statements in pf.conf in order for both Sides on each Network Cards to talk > to >> each other. Say i do not, and it should all just work, does the fact that > it >> does not work suggest that i most likely have a routing issue? >> >> best regards, >> D >> >> On May 17, 2011, at 9:29 PM, David Gwynne wrote: >> >>> hey david, >>> >>> pf is run twice on packets going through a box, once before the network >> stack >>> and again as it leaves it. this means you have to allow a packet in one >> side >>> as well as when it goes out the other. >>> >>> dlg >>> >>> On 17/05/2011, at 10:16 PM, David Schulz wrote: >>> >>>> Hi all, >>>> >>>> i have a LAN within a LAN and the setup is as follows: >>>> >>>> 192.168.1.0/24 <-- OpenBSD 4.9 Router with 2 NICS --> 10.1.0.0/21 >>>> >>>> My goal is to get both Sides talking to each other (lets start with > making >>>> them be able to ping each other). I got it working by using the following >>>> pf.conf, however i thought i should not need to have those match out >>>> statements, because OpenBSD routes packets between interfaces by default >> as >>>> long sysctl net.inet.ip.forwa
Re: Routing Issue
Put a route !? 2011/5/18 David Schulz > Hi there, > > if i disable pf, it will not work (except when trying from router itself > via > ssh). Here some output from hostname.ifs and mygate, my routing table. > Would > be most grateful for any tips that help solving this. > > Best regards, > D > > cndlne001'root(~)> cat /etc/hostname.sis0 > inet 10.1.3.19 255.255.254.0 NONE > cndlne001'root(~)> cat /etc/hostname.sis1 > inet 192.168.1.1 255.255.255.0 NONE > cndlne001'root(~)> cat /etc/mygate > 10.1.3.1 > cndlne001'root(~)> route -n show > Routing tables > > Internet: > DestinationGatewayFlags Refs Use Mtu Prio > Iface > default10.1.3.1 UGS03 - 8 > sis0 > 10.1.2/23 link#1 UC 40 - 4 > sis0 > 10.1.3.1 00:18:4d:33:e3:df UHLc 10 - 4 > sis0 > 10.1.3.7 f4:ce:46:b1:a6:26 UHLc 1 10 - 4 > sis0 > 10.1.3.37 20:cf:30:56:15:80 UHLc 1 107 - 4 > sis0 > 10.1.3.46 1c:af:f7:0e:17:20 UHLc 0 41 - 4 > sis0 > 127/8 127.0.0.1 UGRS 00 33200 8 lo0 > 127.0.0.1 127.0.0.1 UH 10 33200 4 lo0 > 192.168.1/24 link#2 UC 10 - 4 > sis1 > 192.168.1.200:14:97:02:2b:b2 UHLc 0 41 - 4 > sis1 > 224/4 127.0.0.1 URS00 33200 8 lo0 > > cndlne001'root(~)> sysctl net.inet.ip.forwarding > net.inet.ip.forwarding=1 > > sis0: flags=8843 mtu 1500 >lladdr 00:00:24:ca:a9:f4 >priority: 0 >groups: egress >media: Ethernet autoselect (100baseTX full-duplex) >status: active >inet 10.1.3.19 netmask 0xfe00 broadcast 10.1.3.255 >inet6 fe80::200:24ff:feca:a9f4%sis0 prefixlen 64 scopeid 0x1 > cndlne001'root(~)> ifconfig sis1 > sis1: flags=8843 mtu 1500 >lladdr 00:00:24:ca:a9:f5 >priority: 0 >media: Ethernet autoselect (100baseTX full-duplex) >status: active >inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 >inet6 fe80::200:24ff:feca:a9f5%sis1 prefixlen 64 scopeid 0x2 > cndlne001'root(~)> > > > On May 18, 2011, at 2:29 PM, Aaron Mason wrote: > > > If you've disabled pf and it doesn't, then yes, possibly. > > > > If the network is configured like this: > > > > 192.168.1.0/24]192.168.1.1(em0)[Router]10.1.0.1(em1)[10.1.0.0/21 > > > > Setting the default routes to the required interface on each side > > should allow packets to flow freely from end to end. There should be > > no need for PF trickery unless you wish to restrict access to certain > > machines on either side. > > > > Your best test is a traceroute. Perform a traceroute from one side to > > the other, and see what the last step is before you get a string of > > timeouts. > > > > All said, I see rules in your PF that allow certain ICMP types, but > > haven't included the echo response - that's probably why you can't > > ping across the router. > > > > On Wed, May 18, 2011 at 3:29 PM, David Schulz > > wrote: > >> Basically i am just trying to verify whether i actually do need the > match > > out > >> statements in pf.conf in order for both Sides on each Network Cards to > talk > > to > >> each other. Say i do not, and it should all just work, does the fact > that > > it > >> does not work suggest that i most likely have a routing issue? > >> > >> best regards, > >> D > >> > >> On May 17, 2011, at 9:29 PM, David Gwynne wrote: > >> > >>> hey david, > >>> > >>> pf is run twice on packets going through a box, once before the network > >> stack > >>> and again as it leaves it. this means you have to allow a packet in one > >> side > >>> as well as when it goes out the other. > >>> > >>> dlg > >>> > >>> On 17/05/2011, at 10:16 PM, David Schulz wrote: > >>> > >>>> Hi all, > >>>> > >>>> i have a LAN within a LAN and the setup is as follows: > >>>> > >>>> 192.168.1.0/24 <-- OpenBSD 4.9 Router with 2 NICS --> 10.1.0.0/21 > >>>> > >>>> My goal is to get both Sides talking to each other (lets start with > &g
Re: Routing Issue
Hi there, if i disable pf, it will not work (except when trying from router itself via ssh). Here some output from hostname.ifs and mygate, my routing table. Would be most grateful for any tips that help solving this. Best regards, D cndlne001'root(~)> cat /etc/hostname.sis0 inet 10.1.3.19 255.255.254.0 NONE cndlne001'root(~)> cat /etc/hostname.sis1 inet 192.168.1.1 255.255.255.0 NONE cndlne001'root(~)> cat /etc/mygate 10.1.3.1 cndlne001'root(~)> route -n show Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface default10.1.3.1 UGS03 - 8 sis0 10.1.2/23 link#1 UC 40 - 4 sis0 10.1.3.1 00:18:4d:33:e3:df UHLc 10 - 4 sis0 10.1.3.7 f4:ce:46:b1:a6:26 UHLc 1 10 - 4 sis0 10.1.3.37 20:cf:30:56:15:80 UHLc 1 107 - 4 sis0 10.1.3.46 1c:af:f7:0e:17:20 UHLc 0 41 - 4 sis0 127/8 127.0.0.1 UGRS 00 33200 8 lo0 127.0.0.1 127.0.0.1 UH 10 33200 4 lo0 192.168.1/24 link#2 UC 10 - 4 sis1 192.168.1.200:14:97:02:2b:b2 UHLc 0 41 - 4 sis1 224/4 127.0.0.1 URS00 33200 8 lo0 cndlne001'root(~)> sysctl net.inet.ip.forwarding net.inet.ip.forwarding=1 sis0: flags=8843 mtu 1500 lladdr 00:00:24:ca:a9:f4 priority: 0 groups: egress media: Ethernet autoselect (100baseTX full-duplex) status: active inet 10.1.3.19 netmask 0xfe00 broadcast 10.1.3.255 inet6 fe80::200:24ff:feca:a9f4%sis0 prefixlen 64 scopeid 0x1 cndlne001'root(~)> ifconfig sis1 sis1: flags=8843 mtu 1500 lladdr 00:00:24:ca:a9:f5 priority: 0 media: Ethernet autoselect (100baseTX full-duplex) status: active inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 inet6 fe80::200:24ff:feca:a9f5%sis1 prefixlen 64 scopeid 0x2 cndlne001'root(~)> On May 18, 2011, at 2:29 PM, Aaron Mason wrote: > If you've disabled pf and it doesn't, then yes, possibly. > > If the network is configured like this: > > 192.168.1.0/24]192.168.1.1(em0)[Router]10.1.0.1(em1)[10.1.0.0/21 > > Setting the default routes to the required interface on each side > should allow packets to flow freely from end to end. There should be > no need for PF trickery unless you wish to restrict access to certain > machines on either side. > > Your best test is a traceroute. Perform a traceroute from one side to > the other, and see what the last step is before you get a string of > timeouts. > > All said, I see rules in your PF that allow certain ICMP types, but > haven't included the echo response - that's probably why you can't > ping across the router. > > On Wed, May 18, 2011 at 3:29 PM, David Schulz > wrote: >> Basically i am just trying to verify whether i actually do need the match > out >> statements in pf.conf in order for both Sides on each Network Cards to talk > to >> each other. Say i do not, and it should all just work, does the fact that > it >> does not work suggest that i most likely have a routing issue? >> >> best regards, >> D >> >> On May 17, 2011, at 9:29 PM, David Gwynne wrote: >> >>> hey david, >>> >>> pf is run twice on packets going through a box, once before the network >> stack >>> and again as it leaves it. this means you have to allow a packet in one >> side >>> as well as when it goes out the other. >>> >>> dlg >>> >>> On 17/05/2011, at 10:16 PM, David Schulz wrote: >>> >>>> Hi all, >>>> >>>> i have a LAN within a LAN and the setup is as follows: >>>> >>>> 192.168.1.0/24 <-- OpenBSD 4.9 Router with 2 NICS --> 10.1.0.0/21 >>>> >>>> My goal is to get both Sides talking to each other (lets start with > making >>>> them be able to ping each other). I got it working by using the following >>>> pf.conf, however i thought i should not need to have those match out >>>> statements, because OpenBSD routes packets between interfaces by default >> as >>>> long sysctl net.inet.ip.forwarding=1 is set. >>>> >>>> From inside my OpenBSD Box i can ping Devices on either Side just fine. >> From >>> a >>>> machine sitting on either Side, i can ping the OpenBSD Box just fine. But >> i >>>> simply cannot get Side A Machines
Re: Routing Issue
If you've disabled pf and it doesn't, then yes, possibly.
If the network is configured like this:
192.168.1.0/24]192.168.1.1(em0)[Router]10.1.0.1(em1)[10.1.0.0/21
Setting the default routes to the required interface on each side
should allow packets to flow freely from end to end. There should be
no need for PF trickery unless you wish to restrict access to certain
machines on either side.
Your best test is a traceroute. Perform a traceroute from one side to
the other, and see what the last step is before you get a string of
timeouts.
All said, I see rules in your PF that allow certain ICMP types, but
haven't included the echo response - that's probably why you can't
ping across the router.
On Wed, May 18, 2011 at 3:29 PM, David Schulz
wrote:
> Basically i am just trying to verify whether i actually do need the match
out
> statements in pf.conf in order for both Sides on each Network Cards to talk
to
> each other. Say i do not, and it should all just work, does the fact that
it
> does not work suggest that i most likely have a routing issue?
>
> best regards,
> D
>
> On May 17, 2011, at 9:29 PM, David Gwynne wrote:
>
>> hey david,
>>
>> pf is run twice on packets going through a box, once before the network
> stack
>> and again as it leaves it. this means you have to allow a packet in one
> side
>> as well as when it goes out the other.
>>
>> dlg
>>
>> On 17/05/2011, at 10:16 PM, David Schulz wrote:
>>
>>> Hi all,
>>>
>>> i have a LAN within a LAN and the setup is as follows:
>>>
>>> 192.168.1.0/24 <-- OpenBSD 4.9 Router with 2 NICS --> 10.1.0.0/21
>>>
>>> My goal is to get both Sides talking to each other (lets start with
making
>>> them be able to ping each other). I got it working by using the following
>>> pf.conf, however i thought i should not need to have those match out
>>> statements, because OpenBSD routes packets between interfaces by default
> as
>>> long sysctl net.inet.ip.forwarding=1 is set.
>>>
>>> From inside my OpenBSD Box i can ping Devices on either Side just fine.
> From
>> a
>>> machine sitting on either Side, i can ping the OpenBSD Box just fine. But
> i
>>> simply cannot get Side A Machines to talk to Side B Machines unless i
>>> uncomment the two below match out statements inside my pf.conf.
>>>
>>> If someone could share some insight, id be most thankful.
>>>
>>> regards,
>>> D
>>>
>>> Here my simplified pf.conf which again does not work unless i uncomment
> the
>>> two match out Rules:
>>> pf.conf
>>> int_if="sis0"
>>> ext_if="sis1"
>>>
>>> icmp_types = "{ echoreq, unreach }"
>>>
>>> set require-order yes
>>> set block-policy return
>>> set optimization normal
>>> set loginterface $ext_if
>>>
>>> match in all scrub (no-df)
>>>
>>> set skip on lo
>>>
>>> #match out on $int_if from 192.168.1.0/24 to any nat-to ($int_if)
>>> #match out on $ext_if from 10.1.0.0/21 to any nat-to ($ext_if)
>>>
>>> block log all
>>>
>>> #Simplified for 'making it work purposes'
>>> pass out quick
>>> pass in quick
>>>
>>> antispoof quick for { lo0 $int_if $ext_if } inet
>>>
>>> # allow ICMP
>>> pass in quick on { $int_if $ext_if } inet proto icmp all icmp-type
>> $icmp_types
>>> keep state
>>>
>>>
>>> route -n
>>> cndlne001'root(~)> route -n show | grep default
>>> default10.1.3.1 UGS023106 - 8
>> sis0
>>>
>>> cndlne001'root(~)> route -n show | grep 192.168.1
>>> 192.168.1/24 link#2 UC 20 - 4
>> sis1
>
>
--
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse
Re: Routing Issue
Basically i am just trying to verify whether i actually do need the match out
statements in pf.conf in order for both Sides on each Network Cards to talk to
each other. Say i do not, and it should all just work, does the fact that it
does not work suggest that i most likely have a routing issue?
best regards,
D
On May 17, 2011, at 9:29 PM, David Gwynne wrote:
> hey david,
>
> pf is run twice on packets going through a box, once before the network
stack
> and again as it leaves it. this means you have to allow a packet in one
side
> as well as when it goes out the other.
>
> dlg
>
> On 17/05/2011, at 10:16 PM, David Schulz wrote:
>
>> Hi all,
>>
>> i have a LAN within a LAN and the setup is as follows:
>>
>> 192.168.1.0/24 <-- OpenBSD 4.9 Router with 2 NICS --> 10.1.0.0/21
>>
>> My goal is to get both Sides talking to each other (lets start with making
>> them be able to ping each other). I got it working by using the following
>> pf.conf, however i thought i should not need to have those match out
>> statements, because OpenBSD routes packets between interfaces by default
as
>> long sysctl net.inet.ip.forwarding=1 is set.
>>
>> From inside my OpenBSD Box i can ping Devices on either Side just fine.
From
> a
>> machine sitting on either Side, i can ping the OpenBSD Box just fine. But
i
>> simply cannot get Side A Machines to talk to Side B Machines unless i
>> uncomment the two below match out statements inside my pf.conf.
>>
>> If someone could share some insight, id be most thankful.
>>
>> regards,
>> D
>>
>> Here my simplified pf.conf which again does not work unless i uncomment
the
>> two match out Rules:
>> pf.conf
>> int_if="sis0"
>> ext_if="sis1"
>>
>> icmp_types = "{ echoreq, unreach }"
>>
>> set require-order yes
>> set block-policy return
>> set optimization normal
>> set loginterface $ext_if
>>
>> match in all scrub (no-df)
>>
>> set skip on lo
>>
>> #match out on $int_if from 192.168.1.0/24 to any nat-to ($int_if)
>> #match out on $ext_if from 10.1.0.0/21 to any nat-to ($ext_if)
>>
>> block log all
>>
>> #Simplified for 'making it work purposes'
>> pass out quick
>> pass in quick
>>
>> antispoof quick for { lo0 $int_if $ext_if } inet
>>
>> # allow ICMP
>> pass in quick on { $int_if $ext_if } inet proto icmp all icmp-type
> $icmp_types
>> keep state
>>
>>
>> route -n
>> cndlne001'root(~)> route -n show | grep default
>> default10.1.3.1 UGS023106 - 8
> sis0
>>
>> cndlne001'root(~)> route -n show | grep 192.168.1
>> 192.168.1/24 link#2 UC 20 - 4
> sis1
Re: Routing Issue
Hey David,
I was doing the testing more less the same scenario with yours and having the
source NAT issue.
Below is my diagram:
There are 2 scenarios that I did:
1.without nat (successfull) - can ping from notebook <-->webserver, notebook
can
access webserver/tcp-443 successfully
2.With source NAT(not successfull)
The diagram is:
notebookem0[OpenBSD 4.9 PF]em1-webserver(TCP/443)
Detail:
em0 is 192.168.1.216/24
notebook is 192.168.1.21/24
em1 is 192.168.2.216/24
webserver is 192.168.2.80/24
IP alias for source NAT on em1 is 192.168.2.232/32
ip forwarding on sysctl =1
Notebook's gateway is firewall internal IP: 192.168.1.216
Firewall's gateway is webserver :192.168.2.80
Webserver's gateway is firewall external IP: 192.168.2.216
I have tried to do source NAT testing to allow traffic from notebook to
webserver using source NAT on em1.
192.168.1.21-->192.168.2.232-->192.168.2.80
For the routing table,I don't have other static routes. Only default gateway
which is pointing to 192.168.2.80(webserver)
Unfortunately it hasn't worked at all. I have tried to monitor the traffic using
1.tcpdump on em1(external int) but there are no packets pass through em1 at all.
2.tcpdump on em0(internal int), there are some packets from 192.168.1.21 to
192.168.2.80 (syn) but no reply at all from webserver.
Below is the rule of the scenario above using NAT:
# Tables: (2)
table { 192.168.1.216 , 192.168.2.216 }
table { 192.168.1.216 , 192.168.2.80 , 192.168.2.216 }
#
# Rule 0 (NAT)
match out on em1 proto {tcp udp icmp} from 192.168.1.21 to 192.168.2.80 nat-to
192.168.2.232
#ssh access rule
pass in quick inet proto tcp from 192.168.1.21 to port 22 label
"RULE -1 -- ACCEPT "
#
# Rule 0
pass log quick on { em0 em1 ) inet proto icmp from any to
# Rule 1 (em1,em0)
pass log quick on em1 inet proto tcp from 192.168.2.232 to 192.168.2.80
port
443
block quick inet from any to any no state
Stefan
From: David Gwynne
To: David Schulz
Cc: misc@openbsd.org
Sent: Tue, May 17, 2011 9:29:13 PM
Subject: Re: Routing Issue
hey david,
pf is run twice on packets going through a box, once before the network stack
and again as it leaves it. this means you have to allow a packet in one side
as well as when it goes out the other.
dlg
On 17/05/2011, at 10:16 PM, David Schulz wrote:
> Hi all,
>
> i have a LAN within a LAN and the setup is as follows:
>
> 192.168.1.0/24 <-- OpenBSD 4.9 Router with 2 NICS --> 10.1.0.0/21
>
> My goal is to get both Sides talking to each other (lets start with making
> them be able to ping each other). I got it working by using the following
> pf.conf, however i thought i should not need to have those match out
> statements, because OpenBSD routes packets between interfaces by default as
> long sysctl net.inet.ip.forwarding=1 is set.
>
> From inside my OpenBSD Box i can ping Devices on either Side just fine. From
a
> machine sitting on either Side, i can ping the OpenBSD Box just fine. But i
> simply cannot get Side A Machines to talk to Side B Machines unless i
> uncomment the two below match out statements inside my pf.conf.
>
> If someone could share some insight, id be most thankful.
>
> regards,
> D
>
> Here my simplified pf.conf which again does not work unless i uncomment the
> two match out Rules:
> pf.conf
> int_if="sis0"
> ext_if="sis1"
>
> icmp_types = "{ echoreq, unreach }"
>
> set require-order yes
> set block-policy return
> set optimization normal
> set loginterface $ext_if
>
> match in all scrub (no-df)
>
> set skip on lo
>
> #match out on $int_if from 192.168.1.0/24 to any nat-to ($int_if)
> #match out on $ext_if from 10.1.0.0/21 to any nat-to ($ext_if)
>
> block log all
>
> #Simplified for 'making it work purposes'
> pass out quick
> pass in quick
>
> antispoof quick for { lo0 $int_if $ext_if } inet
>
> # allow ICMP
> pass in quick on { $int_if $ext_if } inet proto icmp all icmp-type
$icmp_types
> keep state
>
>
> route -n
> cndlne001'root(~)> route -n show | grep default
> default10.1.3.1 UGS023106 - 8
sis0
>
> cndlne001'root(~)> route -n show | grep 192.168.1
> 192.168.1/24 link#2 UC 20 - 4
sis1
Re: Routing Issue
hey david,
pf is run twice on packets going through a box, once before the network stack
and again as it leaves it. this means you have to allow a packet in one side
as well as when it goes out the other.
dlg
On 17/05/2011, at 10:16 PM, David Schulz wrote:
> Hi all,
>
> i have a LAN within a LAN and the setup is as follows:
>
> 192.168.1.0/24 <-- OpenBSD 4.9 Router with 2 NICS --> 10.1.0.0/21
>
> My goal is to get both Sides talking to each other (lets start with making
> them be able to ping each other). I got it working by using the following
> pf.conf, however i thought i should not need to have those match out
> statements, because OpenBSD routes packets between interfaces by default as
> long sysctl net.inet.ip.forwarding=1 is set.
>
> From inside my OpenBSD Box i can ping Devices on either Side just fine. From
a
> machine sitting on either Side, i can ping the OpenBSD Box just fine. But i
> simply cannot get Side A Machines to talk to Side B Machines unless i
> uncomment the two below match out statements inside my pf.conf.
>
> If someone could share some insight, id be most thankful.
>
> regards,
> D
>
> Here my simplified pf.conf which again does not work unless i uncomment the
> two match out Rules:
> pf.conf
> int_if="sis0"
> ext_if="sis1"
>
> icmp_types = "{ echoreq, unreach }"
>
> set require-order yes
> set block-policy return
> set optimization normal
> set loginterface $ext_if
>
> match in all scrub (no-df)
>
> set skip on lo
>
> #match out on $int_if from 192.168.1.0/24 to any nat-to ($int_if)
> #match out on $ext_if from 10.1.0.0/21 to any nat-to ($ext_if)
>
> block log all
>
> #Simplified for 'making it work purposes'
> pass out quick
> pass in quick
>
> antispoof quick for { lo0 $int_if $ext_if } inet
>
> # allow ICMP
> pass in quick on { $int_if $ext_if } inet proto icmp all icmp-type
$icmp_types
> keep state
>
>
> route -n
> cndlne001'root(~)> route -n show | grep default
> default10.1.3.1 UGS023106 - 8
sis0
>
> cndlne001'root(~)> route -n show | grep 192.168.1
> 192.168.1/24 link#2 UC 20 - 4
sis1
Routing Issue
Hi all,
i have a LAN within a LAN and the setup is as follows:
192.168.1.0/24 <-- OpenBSD 4.9 Router with 2 NICS --> 10.1.0.0/21
My goal is to get both Sides talking to each other (lets start with making
them be able to ping each other). I got it working by using the following
pf.conf, however i thought i should not need to have those match out
statements, because OpenBSD routes packets between interfaces by default as
long sysctl net.inet.ip.forwarding=1 is set.
>From inside my OpenBSD Box i can ping Devices on either Side just fine. From a
machine sitting on either Side, i can ping the OpenBSD Box just fine. But i
simply cannot get Side A Machines to talk to Side B Machines unless i
uncomment the two below match out statements inside my pf.conf.
If someone could share some insight, id be most thankful.
regards,
D
Here my simplified pf.conf which again does not work unless i uncomment the
two match out Rules:
pf.conf
int_if="sis0"
ext_if="sis1"
icmp_types = "{ echoreq, unreach }"
set require-order yes
set block-policy return
set optimization normal
set loginterface $ext_if
match in all scrub (no-df)
set skip on lo
#match out on $int_if from 192.168.1.0/24 to any nat-to ($int_if)
#match out on $ext_if from 10.1.0.0/21 to any nat-to ($ext_if)
block log all
#Simplified for 'making it work purposes'
pass out quick
pass in quick
antispoof quick for { lo0 $int_if $ext_if } inet
# allow ICMP
pass in quick on { $int_if $ext_if } inet proto icmp all icmp-type $icmp_types
keep state
route -n
cndlne001'root(~)> route -n show | grep default
default10.1.3.1 UGS023106 - 8 sis0
cndlne001'root(~)> route -n show | grep 192.168.1
192.168.1/24 link#2 UC 20 - 4 sis1
routing issue with carp
Hello list, I have a setup with 2 firewalls (openbsd 4.7 MP ) and using carp for redundancy. All systems are using the ip number of the inside carp interface as default gateway. There is another router in that subnet that is used to reach another network so i have static route to that network on the firewall systems. For example : clients are in network 10.1.1.0/24 and carp interface ip is 10.1.1.3 and the other router in het network is 10.1.1.1 . Both firewalls also have a ip number on the physical interface in that subnet, for example firewall1 has 10.1.1.7 and firewall2 has 10.1.1.8. The static route on the firewalls is 10.0.0.0/8 via 10.1.1.1 . Now the problem is that not all traffic goes very well to the 10.0.0.0/8 network, most of the traffic takes longer to complete or connections are broken sometimes. The clients are using a terminal client to reach a AS400 system and when they do some print jobs it takes 10 or 20 times much longer to complete that print. The weird thing about this is that when set the client gateway to 10.1.1.7 ( assuming that one is the master) there are no problems , also when i created a static route on the client for 10.0.0.0/8 via 10.1.1.1 . Any have clue how to fix this without placing the other router in a different subnet or using static routes on the clients ? Many thanks, Peter
Re: Strange problem | routing issue
No reason, platform supports 64bit and thought performance will be better on it. Its running well on i386. -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Stuart Henderson Sent: Thursday, February 18, 2010 6:13 PM To: misc@openbsd.org Subject: Re: Strange problem | routing issue On 2010-02-18, Shailesh Tyagi wrote: > It seems there is a bug in routing with current 4.7 amd64 (build 10 Feb.). I > tried i386 and it worked with same configuration and without any issues. Just > to make sure I even tried reinstalling the amd64 once again thinking I might > have made some mistakes the first time but same results. Following are the > dmsegs from both installations. Although you shouldn't have this type of problem with running amd64 (and after unwrapping your dmesg and diffing them, I see no real differences between your logs from amd64 and i386), is there a particular reason you want to run amd64 on routers rather than i386? > OpenBSD 4.7-beta (GENERIC.MP) #85: Sun Feb 7 17:06:57 MST 2010 Using the MP kernel adds overheads which you probably won't recoup on a router, particularly if you're just taking defaults from upstream (you'd be more likely to see a difference if e.g. you're doing a lot of route filtering or running a route-reflector). > As soon as we start traffic bgp server starts behaving strangely. for example > if we ping any IP, customer side or towards upstream from the bgpd server, > first few seconds we get "no route to host" and after few seconds it starts > getting the response. When we try to ping the same IP again, behavior remain > unchanged. which means it can't get the route for few seconds. We have checked It might be useful to include output from 'route -n monitor' while this is happening. But please, turn off line wrapping in your mail client, it makes your posts very difficult to read. > xxx.xxx.53.0 link#9 UHLc 01 - 4 > > vlan101 > > xxx.xxx.53.0/30link#9 UC 20 - 4 > > vlan101 > > xxx.xxx.53.2 link#9 UHRLc 115 - 4 > > vlan101 This is odd (similar for the other subnets in your output). Why the cloned host entry for 203.153.53.0? Where is the lo0 entry for 203.153.53.1 that hostname.vlan101 suggests should be there? Looking at ifconfig -A output might give a clue. (btw, you might as well skip obfuscating the addresses/ASN, it just makes it harder to read and doesn't hide anything). CONFIDENTIALITY NOTE : The documents herein contain information, belonging to Novanet Ltd, which is confidential and privileged. Unless you are the intended recipient, you may not use, copy or disclose to anyone the documents or any information contained in or attached to the documents.
Re: Strange problem | routing issue
On 2010-02-18, Shailesh Tyagi wrote: > It seems there is a bug in routing with current 4.7 amd64 (build 10 Feb.). I > tried i386 and it worked with same configuration and without any issues. Just > to make sure I even tried reinstalling the amd64 once again thinking I might > have made some mistakes the first time but same results. Following are the > dmsegs from both installations. Although you shouldn't have this type of problem with running amd64 (and after unwrapping your dmesg and diffing them, I see no real differences between your logs from amd64 and i386), is there a particular reason you want to run amd64 on routers rather than i386? > OpenBSD 4.7-beta (GENERIC.MP) #85: Sun Feb 7 17:06:57 MST 2010 Using the MP kernel adds overheads which you probably won't recoup on a router, particularly if you're just taking defaults from upstream (you'd be more likely to see a difference if e.g. you're doing a lot of route filtering or running a route-reflector). > As soon as we start traffic bgp server starts behaving strangely. for example > if we ping any IP, customer side or towards upstream from the bgpd server, > first few seconds we get "no route to host" and after few seconds it starts > getting the response. When we try to ping the same IP again, behavior remain > unchanged. which means it can't get the route for few seconds. We have checked It might be useful to include output from 'route -n monitor' while this is happening. But please, turn off line wrapping in your mail client, it makes your posts very difficult to read. > xxx.xxx.53.0 link#9 UHLc 01 - 4 > > vlan101 > > xxx.xxx.53.0/30link#9 UC 20 - 4 > > vlan101 > > xxx.xxx.53.2 link#9 UHRLc 115 - 4 > > vlan101 This is odd (similar for the other subnets in your output). Why the cloned host entry for 203.153.53.0? Where is the lo0 entry for 203.153.53.1 that hostname.vlan101 suggests should be there? Looking at ifconfig -A output might give a clue. (btw, you might as well skip obfuscating the addresses/ASN, it just makes it harder to read and doesn't hide anything).
Re: Strange problem | routing issue
5/cdrom removable isa0 at pcib0 isadma0
at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo pckbc0 at isa0 port
0x60/5
kbc: cmd word write error
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
mtrr: Pentium Pro MTRR support
uhub2 at uhub0 port 1 "vendor 0x8087 product 0x0020" rev 2.00/0.00 addr 2
uhub3 at uhub1 port 1 "vendor 0x8087 product 0x0020" rev 2.00/0.00 addr 2
uhub4 at uhub3 port 5 "Standard Microsystems product 0x2514" rev 2.00/0.00
addr 3 uhidev0 at uhub4 port 2 configuration 1 interface 0 "DELL Dell QuietKey
Keyboard" rev 1.10/1.01 addr 4
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 modifier keys, 6 key codes wskbd0 at ukbd0 mux 1
wskbd0: connecting to wsdisplay0
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
root on sd0a swap on sd0b dump on sd0b
cpu4: unknown i686 model 0x1e, can't get bus clock (0x0)
cpu1: unknown i686 model 0x1e, can't get bus clock (0x0)
cpu5: unknown i686 model 0x1e, can't get bus clock (0x0)
cpu2: unknown i686 model 0x1e, can't get bus clock (0x0)
cpu6: unknown i686 model 0x1e, can't get bus clock (0x0)
cpu3: unknown i686 model 0x1e, can't get bus clock (0x0)
cpu7: unknown i686 model 0x1e, can't get bus clock (0x0)
bnx0: address 00:26:b9:7b:6e:21
brgphy0 at bnx0 phy 1: BCM5709 10/100/1000baseT PHY, rev. 8
bnx1: address 00:26:b9:7b:6e:22
brgphy1 at bnx1 phy 1: BCM5709 10/100/1000baseT PHY, rev. 8
wskbd0: disconnecting from wsdisplay0
wskbd0 detached
ukbd0 detached
uhidev0 detached
arp info overwritten for 192.168.2.155 by 00:0e:0c:4d:5f:4b on em2
hw.sensors.cpu0.temp0=38.00 degC
-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Shailesh Tyagi
Sent: Thursday, February 11, 2010 7:31 PM
To: misc@openbsd.org
Subject: Strange problem | routing issue
Hello,
We are facing a strange problem while trying to use openbgpd. We would like to
use openbgpd as our core BGP router on a Dell Poweredge R210 server with quad
core xeon/ 8 GB RAM/ 6 x1GB ports (2 on board Broadcom and quad port Intel
adapter). 4.6 stable installation failed because it could not detect hard disk
(I guess its related to the controller). Then we installed current 4.7
amd64(10 Feb build) which detected the HDD and installed properly. After
configuring BGPD everything camp up nicely.
--The Setup-
Customers-Cisco SW 2950 (8xVLAN)-(1GB Vlan
trunk)--|||BGPD
Server||-(100Mbps)--Upstream carrier
-
--
Bgpd.conf
# $OpenBSD: bgpd.conf,v 1.9 2009/11/20 19:51:05 claudio Exp $
# global configuration
AS xxx13
router-id xxx.xxx.53.1
network xxx.xxx.52.0/22
# neighbors and peers
neighbor xxx.xxx.58.21 {
remote-as xx55
descr "upstream"
announceall
tcp md5sig password xxx }
neighbor xxx.xxx.52.202 {
remote-as xxx23
descr "customer"
announcedefault-route
tcp md5sig password x
multihop3
local-address xxx.xxx.53.9
}
# filter out prefixes longer than 24 or shorter than 8 bits deny from any
allow from any inet prefixlen 8 - 24
# accept a default route (since the previous rule blocks this) allow from
xxx.xxx.58.21 prefix 0.0.0.0/0 allow from xxx.xxx.52.202 prefix
xxx.xxx.168.0/24
# filter bogus networks
deny from any prefix 10.0.0.0/8 prefixlen >= 8 deny from any prefix
172.16.0.0/12 prefixlen >= 12 deny from any prefix 192.168.0.0/16 prefixlen >=
16 deny from any prefix 169.254.0.0/16 prefixlen >= 16 deny from any prefix
192.0.2.0/24 prefixlen >= 24 deny from any prefix 224.0.0.0/4 prefixlen >= 4
deny from any prefix 240.0.0.0/4 prefixlen >= 4 Network interfaces
(Hostname.em0) upstream carrier
inet xxx.xxx.58.22 255.255.255.252 xxx.xxx.58.23 media 100baseTX mediaopt
full-duplex description "Upstream carrier"
(Hostname.vlan101) cisco router facing customers and bgpd (for TDM
interfaces)
inet xxx.xxx.53.1 255.255.255.252 xxx.xxx.53.3 vlandev em3 description "Cisco
2821"
! route add xxx.xxx.53.16/30 xxx.xxx.53.2 ! route add xxx.xxx.53.200/29
xxx.xxx.53.2 ! route add xxx.xxx.53.20/30 xxx.xxx.53.2 ! route add
xxx.xxx.53.92/30 xxx.xxx.53.2 ! route add xxx.xxx.53.40/30 xxx.xxx.53.2 !
route add xxx.xxx.53.112/28 xxx.xxx.53.2 ! route add xxx.xxx.53.52/30
xxx.xxx.53.2 ! route add xxx.xxx.53.248/29 xxx.xxx.53.2 ! route add
xxx.xxx.53.80/30 xxx.xxx.53.2 ! route add xxx.xxx.53.84/30 xxx.xxx.53.2 !
route add xxx.xxx.53.88/30 xxx.xxx.53.2
(Hostname.vlan102) Customer1
inet xxx.xxx.53.9 255.
Re: Strange problem | routing issue
Shailesh Tyagi [shail...@novanet.net] wrote: > As soon as we start traffic bgp server starts behaving strangely. for example > if we ping any IP, customer side or towards upstream from the bgpd server, > first few seconds we get "no route to host" and after few seconds it starts > getting the response. When we try to ping the same IP again, behavior remain > unchanged. which means it can't get the route for few seconds. We have checked > the media connections and under normal conditions (without bgpd and vlans) > everything works fine. I am not sure if its related to so many vlans, bgpd > configuration or bug in routing daemon. Another strange thing I have noticed > is that it shows 10M memory in "TOP command" where server has 8GB RAM. I am > pasting the dmesg and other logs for your info. > - It's hard to tell from the jumble of obfuscated output that you posted to the list, it sounds like you have a larger network (/24?) directly configured on a local interface, and you are expecting to reach parts of it (/30, /27, etc...) through BGP. You should better plan your network configuration so that you have no overlapping subnets on any of your router interfaces. Chris
Strange problem | routing issue
Hello,
We are facing a strange problem while trying to use openbgpd. We would like to
use openbgpd as our core BGP router on a Dell Poweredge R210 server with quad
core xeon/ 8 GB RAM/ 6 x1GB ports (2 on board Broadcom and quad port Intel
adapter). 4.6 stable installation failed because it could not detect hard disk
(I guess its related to the controller). Then we installed current 4.7
amd64(10 Feb build) which detected the HDD and installed properly. After
configuring BGPD everything camp up nicely.
--The Setup-
Customers-Cisco SW 2950 (8xVLAN)-(1GB Vlan
trunk)--|||BGPD
Server||-(100Mbps)--Upstream carrier
-
--
Bgpd.conf
# $OpenBSD: bgpd.conf,v 1.9 2009/11/20 19:51:05 claudio Exp $
# global configuration
AS xxx13
router-id xxx.xxx.53.1
network xxx.xxx.52.0/22
# neighbors and peers
neighbor xxx.xxx.58.21 {
remote-as xx55
descr "upstream"
announceall
tcp md5sig password xxx
}
neighbor xxx.xxx.52.202 {
remote-as xxx23
descr "customer"
announcedefault-route
tcp md5sig password x
multihop3
local-address xxx.xxx.53.9
}
# filter out prefixes longer than 24 or shorter than 8 bits
deny from any
allow from any inet prefixlen 8 - 24
# accept a default route (since the previous rule blocks this)
allow from xxx.xxx.58.21 prefix 0.0.0.0/0
allow from xxx.xxx.52.202 prefix xxx.xxx.168.0/24
# filter bogus networks
deny from any prefix 10.0.0.0/8 prefixlen >= 8
deny from any prefix 172.16.0.0/12 prefixlen >= 12
deny from any prefix 192.168.0.0/16 prefixlen >= 16
deny from any prefix 169.254.0.0/16 prefixlen >= 16
deny from any prefix 192.0.2.0/24 prefixlen >= 24
deny from any prefix 224.0.0.0/4 prefixlen >= 4
deny from any prefix 240.0.0.0/4 prefixlen >= 4
Network interfaces
(Hostname.em0) upstream carrier
inet xxx.xxx.58.22 255.255.255.252 xxx.xxx.58.23 media 100baseTX mediaopt
full-duplex description "Upstream carrier"
(Hostname.vlan101) cisco router facing customers and bgpd (for TDM
interfaces)
inet xxx.xxx.53.1 255.255.255.252 xxx.xxx.53.3 vlandev em3 description "Cisco
2821"
! route add xxx.xxx.53.16/30 xxx.xxx.53.2
! route add xxx.xxx.53.200/29 xxx.xxx.53.2
! route add xxx.xxx.53.20/30 xxx.xxx.53.2
! route add xxx.xxx.53.92/30 xxx.xxx.53.2
! route add xxx.xxx.53.40/30 xxx.xxx.53.2
! route add xxx.xxx.53.112/28 xxx.xxx.53.2
! route add xxx.xxx.53.52/30 xxx.xxx.53.2
! route add xxx.xxx.53.248/29 xxx.xxx.53.2
! route add xxx.xxx.53.80/30 xxx.xxx.53.2
! route add xxx.xxx.53.84/30 xxx.xxx.53.2
! route add xxx.xxx.53.88/30 xxx.xxx.53.2
(Hostname.vlan102) Customer1
inet xxx.xxx.53.9 255.255.255.252 xxx.xxx.53.11 vlandev em3 description
"customer"
! route add xxx.xxx.52.0/24 xxx.xxx.53.10
! route add xxx.xxx.54.0/25 xxx.xxx.53.10
(hostname.vlan103) Customer2
inet xxx.xxx.53.13 255.255.255.252 xxx.xxx.53.15 vlandev em3 description
"customer2"
! route add xxx.xxx.53.192/29 xxx.xxx.53.14
And like that we have around 8 customers all going thru vlan trunk configured
between bgpd server and cisco switch.
---The Problem-
As soon as we start traffic bgp server starts behaving strangely. for example
if we ping any IP, customer side or towards upstream from the bgpd server,
first few seconds we get "no route to host" and after few seconds it starts
getting the response. When we try to ping the same IP again, behavior remain
unchanged. which means it can't get the route for few seconds. We have checked
the media connections and under normal conditions (without bgpd and vlans)
everything works fine. I am not sure if its related to so many vlans, bgpd
configuration or bug in routing daemon. Another strange thing I have noticed
is that it shows 10M memory in "TOP command" where server has 8GB RAM. I am
pasting the dmesg and other logs for your info.
-
System info
CPU0 states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100%
idle
CPU1 states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100%
idle
CPU2 states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100%
idle
CPU3 states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100%
idle
CPU4 states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100%
idle
CPU5 states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100%
idle
CPU6 states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100%
idle
CPU7 states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100%
idle
Memory: Real: 11M/59M act/tot Free: 2915M Swap: 0K/3318M used/tot
PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND
9436 root 20 3428K 3132K sleep/1 select0:00 0.00% sshd
16649 root 20 3368K 3096K idle select0:00 0.00% sshd
18987 _bgpd 20 776
Re: Routing issue with VPN tunnel [SOLVED]
Hi all, The lo1 workaround worked. There are some posts out there that explain this, or parts of it, and here's my contribution. The two threads I found most helpful can be googled: "NAT on IPSEC with OpenBSD/pf/isakmpd" "OT - NAT on IPsec" The issues in question are mentioned earlier in this thread and I won't repeat them. 1 - Create a loopback interface on which NATting will be done: # cat /etc/hostname.lo1 inet 172.16.0.1 255.255.255.0 NONE description "IPsec NAT interface" This should be an ip of a different subnet than your internal network. 2 - Add a static route to the remote network you are trying to reach: route add 192.168.0.0/24 172.16.0.1 3 - Configure lo1 for nat (pf.conf): nat on lo1 from $internal_net to 192.168.0.0/24 -> lo1 4 - Create pf.conf rules: ## ISAKMP VPN pass on lo1 inet from lo1 to 192.168.0.0/24 keep state # In pass in on enc0 keep state (if-bound) # Out pass out on enc0 inet from lo1 to 192.168.0.0/24 pass on enc0 proto ipencap all keep state (if-bound) pass on $ext_if inet proto esp all keep state --- NB. Outgoing enc0 traffic rule must not contain "keep state" 5 - The ipsec tunnel/flows must of course be added with 172.16.0.1 as IPV4_ADDR. [My-Net] ID-Type=IPV4_ADDR Address= 172.16.0.1 Best regards, Danial
Re: Routing issue with VPN tunnel
On Dec 17, 2008 1:14am, Boris Goldberg wrote: > Hello Danial, > > > > Tuesday, December 16, 2008, 6:55:17 PM, you wrote: > > > > DO> This involves the same issue as mentioned earlier, that the > > DO> flows/"dummy tunnel" does in fact get transmitted to the peer for > > DO> quick mode negotiation. > > > > Yes it does, but why do you care? Does the "real" tunnel stop working > > because of that? No it doesn't, but the remote site doesn't accept anything but my specific ip address. So it restricts me from creating additional "broader" flows. I'm gonna try the aforementioned lo1 hack as soon as they allow the new ip I'm gonna use for NAT. / Danial
Re: Routing issue with VPN tunnel
On Tue, Dec 16, 2008 at 11:17 PM, Boris Goldberg wrote: > Hello Danial, > > Tuesday, December 16, 2008, 4:07:26 PM, you wrote: > >>> Your tunnel is probably host-to-host - don't change it, but add an >>> additional network-to-host one. That "dummy" tunnel wont actually transfer >>> anything, but will route packets from your internal network to enc0, than >>> your nat rule will change it and everything should work. > > DO> I'm not quite sure how you've done this. Could you be more specific? > DO> Do you mean to add an additional Connection in isakmpd.conf and refer > DO> to the same Peer but a different network (Local-ID)? > > Yes, something like the following: > > [Phase 1] > =PIX > > [Phase 2] > Connections=PIX_CONN-1,PIX_CONN-1_1 > > [PIX_CONN-1] > Phase= 2 > ISAKMP-peer=PIX > Configuration= quick-mode-pix > Local-ID= Net-twopoint > Remote-ID= pix-internal-1 > > [PIX_CONN-1_1] > Phase= 2 > ISAKMP-peer=PIX > Configuration= quick-mode-pix > Local-ID= twopoint-internal-1 > Remote-ID= pix-internal-1 > > [Net-twopoint] > ID-type=IPV4_ADDR_SUBNET > Network= > Netmask= > > [twopoint-internal-1] > ID-type= IPV4_ADDR > Address= > > [pix-internal-1] > ID-type= IPV4_ADDR > Address= > > Of course, it's just a quote from our isakmd.conf. Real numbers are > substituted with . This involves the same issue as mentioned earlier, that the flows/"dummy tunnel" does in fact get transmitted to the peer for quick mode negotiation. isakmpd -dvL reports Default transport_send_messages: giving up on exchange PEER, no response from peer :500 isakmpd.pcap contains 00:38:55.138549 .500 > .500: [udp sum ok] isakmp v1.0 exchange QUICK_MODE cookie: 4e4b2944370a8560->ff879e6d83275fd5 msgid: 85e8f8bd len: 284 payload: HASH len: 24 payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 40 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0x8f05b4fc payload: TRANSFORM len: 28 transform: 1 ID: 3DES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 1200 attribute ENCAPSULATION_MODE = TUNNEL attribute AUTHENTICATION_ALGORITHM = HMAC_SHA attribute GROUP_DESCRIPTION = 2 payload: NONCE len: 20 payload: KEY_EXCH len: 132 payload: ID len: 16 type: IPV4_ADDR_SUBNET = /255.255.0.0 payload: ID len: 12 type: IPV4_ADDR = [ttl 0] (id 1, len 312) 00:38:55.218317 .500 > .500: [udp sum ok] isakmp v1.0 exchange INFO cookie: 4e4b2944370a8560->ff879e6d83275fd5 msgid: c2905b70 len: 124 payload: HASH len: 24 payload: NOTIFICATION len: 68 notification: NO PROPOSAL CHOSEN [ttl 0] (id 1, len 152) I'm relying on the lo1 hack to save me. Gonna try it as soon as the IP I'm gonna use gets accepted by the remote site! Thanks, Danial
Re: Routing issue with VPN tunnel
On Tue, Dec 16, 2008 at 3:02 PM, Boris Goldberg wrote: > Hello Danial, > > Sunday, December 14, 2008, 6:06:12 PM, you wrote: > > D> The remote tunnel endpoint expects traffic originating from > D> a specific ip address - the internal ip of the firewall. > >>> I have a tunnel successfully set up between my OpenBSD 3.8 >>> and a Cisco 7200 router. >>> ... >>> There are ACLs on the $remote_gw which only allow traffic >>> NATed with my $int_if ip. Hence this nat in pf.conf: >>> nat on enc0 inet from $int_net to $remote_host -> $int_if >>> ... >>> What I CAN do is ping the $remote_host through the tunnel >>> from the $int_if with the following command: >>> # ping -I $int_if $remote_host >>> >>> This works and replies are received! >>> >>> >>> But if if try pinging from the $internal_host: >>> c:\> ping $remote_host >>> >>> This doesn't work. The packets are not sent through the >>> tunnel but to the internet. > > I have a working tunnel like yours. May be there is a way to do it > "right", but I haven't found one. But here is a workaround: A workaround is just fine by me :) > Your tunnel is probably host-to-host - don't change it, but add an > additional network-to-host one. That "dummy" tunnel wont actually transfer > anything, but will route packets from your internal network to enc0, than > your nat rule will change it and everything should work. I'm not quite sure how you've done this. Could you be more specific? Do you mean to add an additional Connection in isakmpd.conf and refer to the same Peer but a different network (Local-ID)? Thanks for your reply, Danial
Re: Routing issue with VPN tunnel
Hello Danial, Sunday, December 14, 2008, 6:06:12 PM, you wrote: D> The remote tunnel endpoint expects traffic originating from D> a specific ip address - the internal ip of the firewall. >> I have a tunnel successfully set up between my OpenBSD 3.8 >> and a Cisco 7200 router. >> ... >> There are ACLs on the $remote_gw which only allow traffic >> NATed with my $int_if ip. Hence this nat in pf.conf: >> nat on enc0 inet from $int_net to $remote_host -> $int_if >> ... >> What I CAN do is ping the $remote_host through the tunnel >> from the $int_if with the following command: >> # ping -I $int_if $remote_host >> >> This works and replies are received! >> >> >> But if if try pinging from the $internal_host: >> c:\> ping $remote_host >> >> This doesn't work. The packets are not sent through the >> tunnel but to the internet. I have a working tunnel like yours. May be there is a way to do it "right", but I haven't found one. But here is a workaround: Your tunnel is probably host-to-host - don't change it, but add an additional network-to-host one. That "dummy" tunnel wont actually transfer anything, but will route packets from your internal network to enc0, than your nat rule will change it and everything should work. -- Best regards, Borismailto:bo...@twopoint.com
Re: Routing issue with VPN tunnel
On 2008-12-15, Danial Olsen wrote: > Is it possible to nat incoming traffic? no. but there is some hack involving lo1, try google: lo1 nat enc0 >> b) add more flows, mainly >> flow esp out from $int_net to $remote_host peer $remote_gw > > Also tried this. The problem is that the flows are negotiated with the > remote host and it rejects them. Does the remote host really have to > know? hmm, I think there's a diff floating around for this...
Re: Routing issue with VPN tunnel
On Mon, Dec 15, 2008 at 8:46 AM, Claudio Jeker wrote: > On Mon, Dec 15, 2008 at 12:06:12AM +, Danial wrote: >> I don't like responding to my own thread but I really need >> help with this one, so I'll try to rephrase the question: >> >> The remote tunnel endpoint expects traffic originating from >> a specific ip address - the internal ip of the firewall. >> >> How can I achieve this? >> > > I think your setup is worng. See inline. > >> >> On Tue, Dec 9, 2008 at 1:11 PM, do wrote: >> > Hello, >> > >> > I'm having some problems routing traffic through a isakmp >> > vpn tunnel. >> > >> > I have a tunnel successfully set up between my OpenBSD 3.8 >> > and a Cisco 7200 router. >> > I'm not good at ascii art, but here's how I see it: >> > >> > $int_if = 10.0.0.1 >> > $remote_host = 192.168.0.1 >> > >> > >> > $int_if <> enc0 <> $ext_if |> (internet) >> > | |=>$remote_gw<-->$remote_host >> > | >> > | >> > $internal_host >> > >> > >> > >> > There are ACLs on the $remote_gw which only allow traffic >> > NATed with my $int_if ip. Hence this nat in pf.conf: >> > nat on enc0 inet from $int_net to $remote_host -> $int_if >> > > > This nat rule is kicking in to late. Your flow setup will only match > traffic from $int_if to $remote_host. Now even if your default route is > pointing to the $remote_host the traffic from your internal lan will not > match the flow and not end up on enc0. > > I see two possible fixes: > a) nat on the internal interface so that incomming traffic is already > showing up as comming from $inf_if Is it possible to nat incoming traffic? I've tried this but can't seem to get it to work. I can only seem to nat outgoing traffic. > b) add more flows, mainly > flow esp out from $int_net to $remote_host peer $remote_gw Also tried this. The problem is that the flows are negotiated with the remote host and it rejects them. Does the remote host really have to know? > >> > >> > I've established that the flows exist: >> > # netstat -rn -f encap >> > $remote_host/32 0 $int_if/32 0 0 >> > $remote_gw/50/use/in >> > $int_if/32 0 $remote_host/32 0 0 >> > $remote_gw/50/require/out >> > >> > # ipsecctl -s flow >> > flow esp in from $remote_host to $int_if peer $remote_gw >> > flow esp out from $int_if to $remote_host peer $remote_gw >> > >> > >> > What I CAN do is ping the $remote_host through the tunnel >> > from the $int_if with the following command: >> > # ping -I $int_if $remote_host >> > >> > This works and replies are received! >> > >> > >> > But if if try pinging from the $internal_host: >> > c:\> ping $remote_host >> > >> > This doesn't work. The packets are not sent through the >> > tunnel but to the internet. >> > >> > >> > I've tried this route-to line in pf.conf: >> > pass in log quick on $int_if route-to enc0 from $int_net >> to >> > $remote_host keep state >> > >> > And by running tcpdump on pflog0 I can see that packets >> are >> > matched: >> > rule 16/(match) pass out on enc0: $int_if > $remote_host: >> > icmp: echo request >> > >> > But no traffic is sent through the tunnel. >> > >> > >> > Why are pings sent from the $internal_host not matched to >> > the flow/route and sent through the corresponding tunnel? >> > >> > Any help is appreciated in resolving this issue! >> > >> > >> > - Danial >> > > -- > :wq Claudio > > Regards, Danial
Re: Routing issue with VPN tunnel
On Mon, Dec 15, 2008 at 12:06:12AM +, Danial wrote: > I don't like responding to my own thread but I really need > help with this one, so I'll try to rephrase the question: > > The remote tunnel endpoint expects traffic originating from > a specific ip address - the internal ip of the firewall. > > How can I achieve this? > I think your setup is worng. See inline. > > On Tue, Dec 9, 2008 at 1:11 PM, do wrote: > > Hello, > > > > I'm having some problems routing traffic through a isakmp > > vpn tunnel. > > > > I have a tunnel successfully set up between my OpenBSD 3.8 > > and a Cisco 7200 router. > > I'm not good at ascii art, but here's how I see it: > > > > $int_if = 10.0.0.1 > > $remote_host = 192.168.0.1 > > > > > > $int_if <> enc0 <> $ext_if |> (internet) > > | |> $remote_gw <--> > $remote_host > > | > > | > > $internal_host > > > > > > > > There are ACLs on the $remote_gw which only allow traffic > > NATed with my $int_if ip. Hence this nat in pf.conf: > > nat on enc0 inet from $int_net to $remote_host -> $int_if > > This nat rule is kicking in to late. Your flow setup will only match traffic from $int_if to $remote_host. Now even if your default route is pointing to the $remote_host the traffic from your internal lan will not match the flow and not end up on enc0. I see two possible fixes: a) nat on the internal interface so that incomming traffic is already showing up as comming from $inf_if b) add more flows, mainly flow esp out from $int_net to $remote_host peer $remote_gw > > > > I've established that the flows exist: > > # netstat -rn -f encap > > $remote_host/32 0 $int_if/32 0 0 > > $remote_gw/50/use/in > > $int_if/32 0 $remote_host/32 0 0 > > $remote_gw/50/require/out > > > > # ipsecctl -s flow > > flow esp in from $remote_host to $int_if peer $remote_gw > > flow esp out from $int_if to $remote_host peer $remote_gw > > > > > > What I CAN do is ping the $remote_host through the tunnel > > from the $int_if with the following command: > > # ping -I $int_if $remote_host > > > > This works and replies are received! > > > > > > But if if try pinging from the $internal_host: > > c:\> ping $remote_host > > > > This doesn't work. The packets are not sent through the > > tunnel but to the internet. > > > > > > I've tried this route-to line in pf.conf: > > pass in log quick on $int_if route-to enc0 from $int_net > to > > $remote_host keep state > > > > And by running tcpdump on pflog0 I can see that packets > are > > matched: > > rule 16/(match) pass out on enc0: $int_if > $remote_host: > > icmp: echo request > > > > But no traffic is sent through the tunnel. > > > > > > Why are pings sent from the $internal_host not matched to > > the flow/route and sent through the corresponding tunnel? > > > > Any help is appreciated in resolving this issue! > > > > > > - Danial > -- :wq Claudio
Re: Routing issue with VPN tunnel
On Mon, 2008-12-15 at 00:06 +, Danial wrote: > I don't like responding to my own thread but I really need > help with this one, so I'll try to rephrase the question: Just about every userland utility has the ability to specify source transmit addresses (bind(4) function) If not, we can add it. It's probably the second-most-asked question on the Net-SNMP mailing lists (because of all of the embedding, likely) ~BAS > > The remote tunnel endpoint expects traffic originating from IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.
Re: Routing issue with VPN tunnel
I don't like responding to my own thread but I really need help with this one, so I'll try to rephrase the question: The remote tunnel endpoint expects traffic originating from a specific ip address - the internal ip of the firewall. How can I achieve this? / Danial On Tue, Dec 9, 2008 at 1:11 PM, do wrote: > Hello, > > I'm having some problems routing traffic through a isakmp > vpn tunnel. > > I have a tunnel successfully set up between my OpenBSD 3.8 > and a Cisco 7200 router. > I'm not good at ascii art, but here's how I see it: > > $int_if = 10.0.0.1 > $remote_host = 192.168.0.1 > > > $int_if <> enc0 <> $ext_if |> (internet) > | |> $remote_gw <--> $remote_host > | > | > $internal_host > > > > There are ACLs on the $remote_gw which only allow traffic > NATed with my $int_if ip. Hence this nat in pf.conf: > nat on enc0 inet from $int_net to $remote_host -> $int_if > > > I've established that the flows exist: > # netstat -rn -f encap > $remote_host/32 0 $int_if/32 0 0 > $remote_gw/50/use/in > $int_if/32 0 $remote_host/32 0 0 > $remote_gw/50/require/out > > # ipsecctl -s flow > flow esp in from $remote_host to $int_if peer $remote_gw > flow esp out from $int_if to $remote_host peer $remote_gw > > > What I CAN do is ping the $remote_host through the tunnel > from the $int_if with the following command: > # ping -I $int_if $remote_host > > This works and replies are received! > > > But if if try pinging from the $internal_host: > c:\> ping $remote_host > > This doesn't work. The packets are not sent through the > tunnel but to the internet. > > > I've tried this route-to line in pf.conf: > pass in log quick on $int_if route-to enc0 from $int_net to > $remote_host keep state > > And by running tcpdump on pflog0 I can see that packets are > matched: > rule 16/(match) pass out on enc0: $int_if > $remote_host: > icmp: echo request > > But no traffic is sent through the tunnel. > > > Why are pings sent from the $internal_host not matched to > the flow/route and sent through the corresponding tunnel? > > Any help is appreciated in resolving this issue! > > > - Danial
Routing issue with VPN tunnel
Hello, I'm having some problems routing traffic through a isakmp vpn tunnel. I have a tunnel successfully set up between my OpenBSD 3.8 and a Cisco 7200 router. I'm not good at ascii art, but here's how I see it: $int_if = 10.0.0.1 $remote_host = 192.168.0.1 $int_if <> enc0 <> $ext_if |> (internet) | |> $remote_gw <---> $remote_host | | $internal_host There are ACLs on the $remote_gw which only allow traffic NATed with my $int_if ip. Hence this nat in pf.conf: nat on enc0 inet from $int_net to $remote_host -> $int_if I've established that the flows exist: # netstat -rn -f encap $remote_host/32 0 $int_if/32 0 0 $remote_gw/50/use/in $int_if/32 0 $remote_host/32 0 0 $remote_gw/50/require/out # ipsecctl -s flow flow esp in from $remote_host to $int_if peer $remote_gw flow esp out from $int_if to $remote_host peer $remote_gw What I CAN do is ping the $remote_host through the tunnel from the $int_if with the following command: # ping -I $int_if $remote_host This works and replies are received! But if if try pinging from the $internal_host: c:\> ping $remote_host This doesn't work. The packets are not sent through the tunnel but to the internet. I've tried this route-to line in pf.conf: pass in log quick on $int_if route-to enc0 from $int_net to $remote_host keep state And by running tcpdump on pflog0 I can see that packets are matched: rule 16/(match) pass out on enc0: $int_if > $remote_host: icmp: echo request But no traffic is sent through the tunnel. Why are pings sent from the $internal_host not matched to the flow/route and sent through the corresponding tunnel? Any help is appreciated in resolving this issue! - Danial
Re: Strange routing issue
Try 4.3 as the bge driver has some fixes and people are using it in production now with lots of traffic. Joe Warren-Meeks [EMAIL PROTECTED] wrote: > On Wed, May 28, 2008 at 11:37:52AM -0400, Marc-Andre Jutras wrote: > > I had mostly the same issue with my HP Proliant DL320 G5 with obsd 4.1 > > and 4.2 > > > > got some packet lost on the interface without any error on my cisco > > switch -> making my ospf flip and re-calculate route too every 10 sec... > > > > I change all the network cards on this server and it fix my issue... > > looks like there some issue with the BGE / Broadcom drivers... > > > > as a test, try to run a 'mtr' or a high rate ping ( ping -c 1 -i > > 0.01 ) on your interface... make sure you're not getting any packet lost > > for at least 10 min... > > I'm seeing a load of working packets, followed by a load of "No route to > host" and back again. > > Think I'll try swapping to a different card. > > -- joe. > > Why do they have mosaics of hot air balloons at Finsbury Park > station? -- "Guys like us avoid monopolies. We like to compete." -- Bill Gates
OpenBSD 4.0 Routing Issue
Hello all. I have an OpenBSD 4.0 system with three interfaces. My interfaces are setup as follows: /etc/hostname.bge0 inet xx.yy.101.98 255.255.255.224 xx.yy.101.127 /etc/hostname.em0 inet xx.yy.125.130 255.255.255.224 xx.yy.125.159 /etc/hostname.em1 inet 192.168.19.1 255.255.255.0 NONE /etc/mygate xx.yy.125.129 And netstat -rn gives me this: Internet: DestinationGatewayFlagsRefs UseMtu Interface defaultxx.yy.125.129 UGS10 1661 - em0 xx.yy.101.96/27link#3 UC 10 - bge0 xx.yy.101.102 00:01:gg:86:hh:gg UHLc07 - bge0 xx.yy.125.128/27 link#1 UC 10 - em0 xx.yy.125.129 00:18:gg:gg:f5:gg UHLc10 - em0 127/8 127.0.0.1 UGRS00 33224 lo0 127.0.0.1 127.0.0.1 UH 10 33224 lo0 192.168.19/24 link#2 UC 100 - em1 I have pf setup so that 192.168.19.0/24 addresses can access the internet through em0. How do I add a route such that machines on the 192.168.19.0 network can access machines such as xx.yy.101.102 (which should be accessed via bge0). xx.yy.101.102 is currently accessible on a switch that hosts the xx.yy.101.102,xx.yy.125.128 and the 192.168.19.0 networks. All three interfaces are also currently connected to the same switch. The default routes for the xx.yy.101.102 and xx.yy.125.128 networks are also connected via the same switch. Satadru
Re: strange ipv6 routing issue
On Sat, Feb 18, 2006 at 07:22:16AM -0500, David Hill wrote: > > I'm playing with IPv6 in 3.8 and came up to this strange problem. > What do your PF rules look like? arf... I thought about it for a minute or so and discarded the idea. ... and that was the problem... after adding pass quick proto tcp to port ssh keep state to my pf.conf, the connection works... I will inspect my rules thanks ! -- Olivier Mehani <[EMAIL PROTECTED]>
Re: strange ipv6 routing issue
On Sat, Feb 18, 2006 at 12:57:05PM +0100, Olivier Mehani wrote: > Hello list, > > I'm playing with IPv6 in 3.8 and came up to this strange problem. > > My IPv6 connectivity is given by a broker (xs26.net) and I have set up a gif > interface to use it (gif0): > > /etc/hostname.gif0 contains: > > tunnel SIS0IPv4 BROKERIPv4 > inet6 IPv6PREFIX::1 > !route add -inet6 default IPv6PREFIX::1 > > gif0: flags=8151 mtu 1500 > groups: gif > physical address inet SIS0IPv4 --> BROKERIPv4 > inet6 fe80::202:6fff:fe21:ea79%gif0 -> prefixlen 64 scopeid 0x8 > inet6 IPv6PREFIX::1 -> prefixlen 64 > > The funny thing is that I _can_ ping a given machine. > > [EMAIL PROTECTED]:~$ ping6 DISTANTHOSTNAME > PING6(56=40+8+8 bytes) IPv6PREFIX::1 --> DISTANTHOSTIPv6 > 16 bytes from DISTANTHOSTIPv6, icmp_seq=0 hlim=53 time=207.974 ms > 16 bytes from DISTANTHOSTIPv6, icmp_seq=1 hlim=53 time=176.176 ms > 16 bytes from DISTANTHOSTIPv6, icmp_seq=2 hlim=53 time=241.964 ms > 16 bytes from DISTANTHOSTIPv6, icmp_seq=3 hlim=53 time=253.56 ms > ^C > --- zorglub.ssji.net ping6 statistics --- > 4 packets transmitted, 4 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 176.176/219.918/253.560/30.306 ms > > but I get a no route to host when trying to ssh to it > > [EMAIL PROTECTED]:~$ ssh -v6 DISTANTHOSTNAME > OpenSSH_4.1, OpenSSL 0.9.7g 11 Apr 2005 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Connecting to DISTANTHOSTNAME [DISTANTHOSTIPv6] port 22. > debug1: connect to address DISTANTHOSTIPv6 port 22: No route to host > ssh: connect to host DISTANTHOSTNAME port 22: No route to host > > (/etc/ssh/ssh_config reads $OpenBSD: ssh_config,v 1.20 2005/01/28 > 09:45:53 dtucker Exp $ and has not been modified) > > To be even weirder, the machines behind the router, which get IPv6 in the same > prefix manage to ssh to the very same host using IPv6 through the router. > > Does somebody have some ideas/solutions about this problem ? > > Useful information (note the "illegal prefix len" in the output of route for > ::/4, which seems to be what "default" resolves to when route -add'ing) > > [EMAIL PROTECTED]:~$ uname -a > OpenBSD mudrublic.narf.ssji.net 3.8 GENERIC#224 i386 > [EMAIL PROTECTED]:~$ route -n show -inet6 > Routing tables > > Internet6: > DestinationGatewayFlags > Refs > UseMtu Interface > route: illegal prefixlen > ::/4 IPv6PREFIX::1 UGS 0 > 1591 - gif0 > ::1::1UH > 0 > 0 33224 lo0 > IPv6PREFIX::/64link#8 UC 0 > 0 - gif0 > IPv6PREFIX::1 link#8 UHLc0 > 12 - lo0 > IPv6PREFIX:100::/64link#3 UC 0 > 0 - sis1 > IPv6PREFIX:100::1 00:00:24:c4:22:5d UHLc0 > 0 - lo0 > IPv6PREFIX:101::/64link#1 UC 0 > 0 - ath0 > IPv6PREFIX:101::1 00:02:6f:21:ea:79 UHLc0 > 0 - lo0 > IPv6PREFIX:101:211:95ff:febb:812f 00:11:95:bb:81:2f UHLc > 0 1857 - ath0 > IPv6PREFIX:101:230:65ff:fe0f:2795 00:30:65:0f:27:95 UHLc > 02 - ath0 > fe80::%ath0/64 link#1 UC > 0 > 0 - ath0 > fe80::202:6fff:fe21:ea79%ath0 00:02:6f:21:ea:79 UHLc> 0 > 0 - lo0 > fe80::211:95ff:febb:812f%ath0 00:11:95:bb:81:2f UHLc> 0 > 109 - ath0 > fe80::230:65ff:fe0f:2795%ath0 00:30:65:0f:27:95 UHLc> 0 > 4 - ath0 > fe80::%sis0/64 link#2 UC > 0 > 0 - sis0 > fe80::%sis1/64 link#3 UC > 0 > 0 - sis1 > fe80::%lo0/64 fe80::1%lo0U > 0 > 0 - lo0 > fe80::%gif0link#8 UHLc> 0 > 0 - gif0 > fe80::%gif0/64 link#8 UC > 0 > 0 - gif0 > fe80::202:6fff:fe21:ea79%gif0 link#8 UHLc> 0 > 0 - lo0 > fe80::260:8ff:fe34:275f%gif0 link#8 UHLc> 0 > 606 - gif0 > ff01::/32 ::1UC > 0 > 0 - lo0 > ff02::%ath0/32 link#1 UC > 0 > 0 - ath0 > ff02::%sis0/32 link#2 UC > 0 > 0 - sis0 > ff02::%sis1/32 link#3 UC > 0 > 0 - sis1 > ff02::%lo0/32
strange ipv6 routing issue
Hello list, I'm playing with IPv6 in 3.8 and came up to this strange problem. My IPv6 connectivity is given by a broker (xs26.net) and I have set up a gif interface to use it (gif0): /etc/hostname.gif0 contains: tunnel SIS0IPv4 BROKERIPv4 inet6 IPv6PREFIX::1 !route add -inet6 default IPv6PREFIX::1 gif0: flags=8151 mtu 1500 groups: gif physical address inet SIS0IPv4 --> BROKERIPv4 inet6 fe80::202:6fff:fe21:ea79%gif0 -> prefixlen 64 scopeid 0x8 inet6 IPv6PREFIX::1 -> prefixlen 64 The funny thing is that I _can_ ping a given machine. [EMAIL PROTECTED]:~$ ping6 DISTANTHOSTNAME PING6(56=40+8+8 bytes) IPv6PREFIX::1 --> DISTANTHOSTIPv6 16 bytes from DISTANTHOSTIPv6, icmp_seq=0 hlim=53 time=207.974 ms 16 bytes from DISTANTHOSTIPv6, icmp_seq=1 hlim=53 time=176.176 ms 16 bytes from DISTANTHOSTIPv6, icmp_seq=2 hlim=53 time=241.964 ms 16 bytes from DISTANTHOSTIPv6, icmp_seq=3 hlim=53 time=253.56 ms ^C --- zorglub.ssji.net ping6 statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 176.176/219.918/253.560/30.306 ms but I get a no route to host when trying to ssh to it [EMAIL PROTECTED]:~$ ssh -v6 DISTANTHOSTNAME OpenSSH_4.1, OpenSSL 0.9.7g 11 Apr 2005 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to DISTANTHOSTNAME [DISTANTHOSTIPv6] port 22. debug1: connect to address DISTANTHOSTIPv6 port 22: No route to host ssh: connect to host DISTANTHOSTNAME port 22: No route to host (/etc/ssh/ssh_config reads $OpenBSD: ssh_config,v 1.20 2005/01/28 09:45:53 dtucker Exp $ and has not been modified) To be even weirder, the machines behind the router, which get IPv6 in the same prefix manage to ssh to the very same host using IPv6 through the router. Does somebody have some ideas/solutions about this problem ? Useful information (note the "illegal prefix len" in the output of route for ::/4, which seems to be what "default" resolves to when route -add'ing) [EMAIL PROTECTED]:~$ uname -a OpenBSD mudrublic.narf.ssji.net 3.8 GENERIC#224 i386 [EMAIL PROTECTED]:~$ route -n show -inet6 Routing tables Internet6: DestinationGatewayFlagsRefs UseMtu Interface route: illegal prefixlen ::/4 IPv6PREFIX::1 UGS 0 1591 - gif0 ::1::1UH 0 0 33224 lo0 IPv6PREFIX::/64link#8 UC 0 0 - gif0 IPv6PREFIX::1 link#8 UHLc0 12 - lo0 IPv6PREFIX:100::/64link#3 UC 0 0 - sis1 IPv6PREFIX:100::1 00:00:24:c4:22:5d UHLc0 0 - lo0 IPv6PREFIX:101::/64link#1 UC 0 0 - ath0 IPv6PREFIX:101::1 00:02:6f:21:ea:79 UHLc0 0 - lo0 IPv6PREFIX:101:211:95ff:febb:812f 00:11:95:bb:81:2f UHLc 0 1857 - ath0 IPv6PREFIX:101:230:65ff:fe0f:2795 00:30:65:0f:27:95 UHLc 02 - ath0 fe80::%ath0/64 link#1 UC 0 0 - ath0 fe80::202:6fff:fe21:ea79%ath0 00:02:6f:21:ea:79 UHLc0 0 - lo0 fe80::211:95ff:febb:812f%ath0 00:11:95:bb:81:2f UHLc0 109 - ath0 fe80::230:65ff:fe0f:2795%ath0 00:30:65:0f:27:95 UHLc0 4 - ath0 fe80::%sis0/64 link#2 UC 0 0 - sis0 fe80::%sis1/64 link#3 UC 0 0 - sis1 fe80::%lo0/64 fe80::1%lo0U 0 0 - lo0 fe80::%gif0link#8 UHLc0 0 - gif0 fe80::%gif0/64 link#8 UC 0 0 - gif0 fe80::202:6fff:fe21:ea79%gif0 link#8 UHLc0 0 - lo0 fe80::260:8ff:fe34:275f%gif0 link#8 UHLc0 606 - gif0 ff01::/32 ::1UC 0 0 - lo0 ff02::%ath0/32 link#1 UC 0 0 - ath0 ff02::%sis0/32 link#2 UC 0 0 - sis0 ff02::%sis1/32 link#3 UC 0 0 - sis1 ff02::%lo0/32 ::1UC 0 0 - lo0 ff02::%gif0/32 link#8 UC 0 0 - gif0 dmesg not included as it does not seem to be relevant for this problem, correct me if I'm wrong (; thanks -- Olivier Mehani <[EMAIL PROTECTED]>
Routing issue with BIND9 and IPsec
Dear all, I have a very strange interaction between BIND9 and IPsec which I can't understand and I hope someone here can shed some light. An OpenBSD primary DNS server, running BIND9 with a simple named.conf (single view, etc.) also has an IPsec connection over which a tunnel runs connecting two RFC1918 networks. Both endpoints run OpenBSD 3.7-stable (CVS updated yesterday), the hardware is also identical (HP Compaq Proliant DL320): <192.168.160/24>--[DNS box]--- IPsec ---[other endpoint]--<192.168.1/24> X.Y.142.162 X.Y.143.226 the IPsec setup is trivial (from /usr/share/ipsec/vpn simply modifying the values in the script). The IPsec tunnel works perfectly but BIND9 occasionally (apparently when a reload is issued to load a new zone or when an AXFR takes place from the other nameservers for the zones held) starts routing all responses to *any* DNS query via the IPsec tunnel. That is to say that any external query from the routable Internet is responded to by sending packets down the IPsec link to the other endpoint where PF rejects the packet. Any other traffic (traceroute, SSH, ICMP) works perfectly and does not suffer from this issue. When blocks start appearing on the endpoint's logs the fix is simple: on the DNS box "ipsecadm flush" and re-run the VPN script. Obviously this is not too good for a production system since these sudden "DNS via IPsec" changes occur at unpredictable times (diagnostic: dig @nameserver primary.zone.com fails). The details: DNS box:OpenBSD 3.7-stable, /usr/src CVS as of Tuesday evening, BIND9 with trivial modification of named.conf from the OpenBSD distro simply loading the master zones and adding a listen-on restriction, IPsec setup from /usr/share/ipsec/vpn endpoint: OpenBSD 3.7-stable, /usr/src CVS as of Tuesday evening, IPsec setup from /usr/share/ipsec/vpn, PF Example traffic: dns-box# traceroute -n 192.168.1.18 traceroute to 192.168.1.18 (192.168.1.18), 64 hops max, 40 byte packets 1 X.Y.143.226 1.214 ms 1.236 ms 1.272 ms 2 192.168.1.18 1.418 ms 1.415 ms 1.420 ms vpn-endpoint# traceroute -n 192.168.161.162 traceroute to 192.168.161.162 (192.168.161.162), 64 hops max, 40 byte packets 1 X.Y.142.162 1.315 ms 1.322 ms 1.370 ms 2 192.168.161.162 2.399 ms 1.947 ms 1.961 ms vpn-endpoint# netstat -rn -f encap Encap:Source Port DestinationPort Proto SA(Address/Proto/Type/Direction) X.Y.142.162/32 0 X.Y.143.226/32 0 0 X.Y.142.162/50/require/in X.Y.142.162/32 0 X.Y.143.226/32 0 50 X.Y.142.162/50/permit/in X.Y.142.162/32 0 192.168.1/240 0 X.Y.142.162/50/require/in 192.168.161/24 0 X.Y.143.226/32 0 0 X.Y.142.162/50/require/in 192.168.161/24 0 192.168.1/240 0 X.Y.142.162/50/require/in X.Y.143.226/32 0 X.Y.142.162/32 0 0 X.Y.142.162/50/require/out X.Y.143.226/32 0 X.Y.142.162/32 0 50 X.Y.142.162/50/permit/out X.Y.143.226/32 0 192.168.161/24 0 0 X.Y.142.162/50/require/out 192.168.1/24 0 X.Y.142.162/32 0 0 X.Y.142.162/50/require/out 192.168.1/24 0 192.168.161/24 0 0 X.Y.142.162/50/require/out the entries for dns-box are symmetrical to the above. Example snafu from a DNS query to the dns-box: (on vpn-endpoint) Oct 19 11:19:44.884586 rule 80/(match) block out on bge0: X.Y.142.162.53 > 213.207.142.101.3861: [udp sum ok] 31987*- q: SOA? example.com. 1/5/5 example.com. SOA dns.example.com. hostmaster.example.com. [...] Any suggestions more than welcome, Thanks, Arrigo
