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 na...@mips.inka.de wrote: On 2015-06-26, Giancarlo Razzolini grazzol...@gmail.com 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
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
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
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 grazzol...@gmail.com To: Openbsd-Misc misc@openbsd.org 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
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: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
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 grazzol...@gmail.com 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
On 2015-06-26, Giancarlo Razzolini grazzol...@gmail.com 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: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
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
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=8151UP,POINTOPOINT,RUNNING,PROMISC,MULTICAST 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
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=8151UP,POINTOPOINT,RUNNING,PROMISC,MULTICAST 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%lo0U0 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 ::1UC 0 0 - lo0 ff02::%gif0/32
