IPv6 testing
-
By the way, the captive portal stuff does not work yet in 2.0b5. I'm getting this error when enabling it:
php: /status_services.php: The command '/usr/local/sbin/lighttpd -f /var/etc/lighty-CaptivePortal.conf' returned exit code '255', the output was '2011-02-11 00:08:44: (configfile.c.912) source: /var/etc/lighty-CaptivePortal.conf line: 186 pos: 1 parser failed somehow near here: (EOL)'
Not sure if it's related to this gitsync and/or IPv6 and if I can and should report it somewhere. Does anybody know?
I have not touched captive portal at all, so that likely won't work. I'll see if I can somehow duplicate the static route issue. I'll try and setup a new vm and see where that goes.
@Daboom: what needed changing in interface.inc? The routing issue is known. Oh crap, I just rememberd something about the route. I'll go investigate that likely cause.
-
I needed to add the line "set bundle enable ipv6cp" somewhere in the mpd5 config in order to allow it to accept ipv6cp config from my ISP. Now I have no idea where to stick it so I put it under something else that is commonly used. I wonder if you could get away with just putting that line in there anyways and it shouldn't bother anything else during the pppoe setup so it's always enabled kinda thing. If not you would have to make a special option for it in the pppoe section as a optional option. Also the route issue I am not sure if there is one specific for ipv6 in the config for mpd5.
By the way, the captive portal stuff does not work yet in 2.0b5. I'm getting this error when enabling it:
php: /status_services.php: The command '/usr/local/sbin/lighttpd -f /var/etc/lighty-CaptivePortal.conf' returned exit code '255', the output was '2011-02-11 00:08:44: (configfile.c.912) source: /var/etc/lighty-CaptivePortal.conf line: 186 pos: 1 parser failed somehow near here: (EOL)'
Not sure if it's related to this gitsync and/or IPv6 and if I can and should report it somewhere. Does anybody know?
I have not touched captive portal at all, so that likely won't work. I'll see if I can somehow duplicate the static route issue. I'll try and setup a new vm and see where that goes.
@Daboom: what needed changing in interface.inc? The routing issue is known. Oh crap, I just rememberd something about the route. I'll go investigate that likely cause.
-
I just added that line to the mpd5 config section so that is now in the tree, we'll know soon enough if it breaks anything else. Checking the default route issue next.
-
Another question for who might be able to answer it. My traffic logs are now flooded with local LAN IPv6 traffic. Check the attached screenshot. I wonder why. If I do a trace on any of these machines towards the other (which are both on the same physical network and within the same /64 block), it always reaches it directly and not via the pfSense gateway. How come this pfSense gateway does pick up the packet from the LAN anyway and list it as being blocked in the logs?
-
@Databeestje, another one for the todo list I'm assuming anyway. The interface statistics do not count the IPv6 traffic. The traffic graph does display the traffic though. Check the screenshot.
By the way, does it help you if I (we) report IPv6 issues with pfSense 2.0b5 to you via this forum or is your todo list big enough already and you don't want any more issues on the list? :)
-
Another question for who might be able to answer it. My traffic logs are now flooded with local LAN IPv6 traffic. Check the attached screenshot. I wonder why. If I do a trace on any of these machines towards the other (which are both on the same physical network and within the same /64 block), it always reaches it directly and not via the pfSense gateway. How come this pfSense gateway does pick up the packet from the LAN anyway and list it as being blocked in the logs?
Koen, I think that the blocks that you are seeing, are states that have expired.
The same can be seen in v4 after you have, for instance, logged into dropbox with your browser and then closed your browser window.
As far as I know, it's harmless and expected behaviour, but correct me if I'm wrong! -
Sry for the partial uninteresting post, but i just registered and will test this IPv6 "support" out tonight (first time using pfSense, currently running dd-wrt on a 610N).
My ISP suports IPv6 (Databeesje will know it, UNET) and i've filled a subnet request for a /56 (hopefully it arrives today).
Anyway, i was wondering if IPv6 "support" works with 1:1 NAT ?
Currently i have a PPPoE setup where my IPv4 subnet (/28) is routed over (with use of a helper IP outside of that subnet, so that ip terminates at the WAN port of pfSense) i want to route both IPv4 and IPv6 on OPT1 by something like 1:1 NAT (so pfSense is the only one that has firewall rules, getting sick of DMZ and having to adjust the rules by going into the servers themself and adjust the IP tables).
Thnx alot, and GJ on the support / development on IPv6, i wish more router / firewall distributions were doing this, currently its still a not supported feature on a lot of distributions.
PPS, i think i will be lurking a bit longer, first have to install / test pfSense, cant use it with IPv6 untill its integrated into my current setup, but still ^^,
-
@YaNightmare, I'm not sure if what you accomplish is possible with pfSense. Just want to mention that at my colocated server I'm using two pfSense Hyper-V virtualized instances: one configured as an IPv6 bridge so that this is the gatekeeper with the firewall rules in place to allow only specific IPv6 traffic through to the IPv6 hosts behind it, the other configured as an IPv4 IPSec Tunnel to allow my home network to be connected to my private network at the hosting party via an encrypted tunnel. Maybe this kind of touches your similar means as well.
@iFloris, I am experiencing some oddities in my network traffic. I can ping everything without any problems, packet loss or delays (both IPv4 and IPv6), but connecting to IPv6 hosts with i.e. remote desktop takes a long time. Even with hosts on the same physical network. When I enter the IPv4 address of the host it connects directly. I do notice that the IPv6 gateway being used is the fe80:: address of the pfSense box. It does not seem to advertise its normal IPv6 address. Does this work fine at your setup? I'm guessing I maybe need to put in some manual RTADVD commands to advertise the gateway, not sure if it's needed though.
-
@Databeestje, another one for the todo list I'm assuming anyway. The interface statistics do not count the IPv6 traffic. The traffic graph does display the traffic though. Check the screenshot.
By the way, does it help you if I (we) report IPv6 issues with pfSense 2.0b5 to you via this forum or is your todo list big enough already and you don't want any more issues on the list? :)
Just report via the forum, that is the easiest for me to pick up on. I recently added the ipv6 counters to the rrd graphs, you can see the traffic there.
We have not decided regarding the traffic counters how to approach this best. -
Sry for the partial uninteresting post, but i just registered and will test this IPv6 "support" out tonight (first time using pfSense, currently running dd-wrt on a 610N).
My ISP suports IPv6 (Databeesje will know it, UNET) and i've filled a subnet request for a /56 (hopefully it arrives today).
Anyway, i was wondering if IPv6 "support" works with 1:1 NAT ?
Yes, it's called Network Prefix translation. See the NAT page.
I am using a ULA range on the LAN at work and perform a 1:1 binat on the traffic when it leaves the network so it is mapped to the corresponding Global address.
Inversely it works the same, all hosts can be reached via the Global address, it is mapped to the corresponding ULA address internally and just works. This is how I do multi wan at work without the availability of BGP. -
@YaNightmare, I'm not sure if what you accomplish is possible with pfSense. Just want to mention that at my colocated server I'm using two pfSense Hyper-V virtualized instances: one configured as an IPv6 bridge so that this is the gatekeeper with the firewall rules in place to allow only specific IPv6 traffic through to the IPv6 hosts behind it, the other configured as an IPv4 IPSec Tunnel to allow my home network to be connected to my private network at the hosting party via an encrypted tunnel. Maybe this kind of touches your similar means as well.
I am currently using 2 pfSense 2.0b5 VMs with my branch for a IPv6 carp cluster, they perform all the filtering for the DMZ machines. Plain firewall filtering. I use ESX though. Works fine.
-
Actually I'm using two pfSense instances since I assumed that the IPSec functionality can not connect using IPv6 yet. If it can, it saves me a valuable and scarce public IPv4 address ;D I was glad to finally get it to work over IPv4, so I don't dare to touch it to see if it will work with IPV6. @Databeestje do you know if IPSec in pfSense 2.0b5 is IPv6 aware?
-
Actually I'm using two pfSense instances since I assumed that the IPSec functionality can not connect using IPv6 yet. If it can, it saves me a valuable and scarce public IPv4 address ;D I was glad to finally get it to work over IPv4, so I don't dare to touch it to see if it will work with IPV6. @Databeestje do you know if IPSec in pfSense 2.0b5 is IPv6 aware?
Nope, it's already listed like the Captive portal. Captive portal won't work without kernel work, so that's end of the year at it's earliest.
Ipsec should work after some gui modifications.
-
Another question for who might be able to answer it. My traffic logs are now flooded with local LAN IPv6 traffic. Check the attached screenshot. I wonder why. If I do a trace on any of these machines towards the other (which are both on the same physical network and within the same /64 block), it always reaches it directly and not via the pfSense gateway. How come this pfSense gateway does pick up the packet from the LAN anyway and list it as being blocked in the logs?
…
@iFloris, I am experiencing some oddities in my network traffic. I can ping everything without any problems, packet loss or delays (both IPv4 and IPv6), but connecting to IPv6 hosts with i.e. remote desktop takes a long time. Even with hosts on the same physical network. When I enter the IPv4 address of the host it connects directly. I do notice that the IPv6 gateway being used is the fe80:: address of the pfSense box. It does not seem to advertise its normal IPv6 address. Does this work fine at your setup? I'm guessing I maybe need to put in some manual RTADVD commands to advertise the gateway, not sure if it's needed though.
Found the problem! After going through the logs from pfSense I noticed traffic originating from two hosts kept being logged: my two Microsoft domain controllers! And those are the only two ones with static IPv6 addresses. Taking a closer look at their netsh int ipv6 config, I noticed routerdiscovery was set to disabled. This caused Windows not to create a /64 routing entry for itself in the routing table. That on its turned caused every incoming IPv6 LAN packet to be delivered directly thus not showing any oddities in the traceroutes from my clients, but outgoing IPv6 packet from both domain controllers to be routed to the pfSense router first. pfSense on its turn blocked all these LAN to LAN packets. That explains why everything is slow… they all try to communicate with the domain controllers for authorization to access the sources. This caused the wildest problems.. Microsoft DFS to be extremely slow, Outlook being able to communicate with Exchange, only the Send as Behalf of function not to work any longer, Remote Desktops to not connect over IPv6, etc. I now turned on routerdiscovery again, added a static reservation entry in the Windows DHCPv6 server and all works fluently and fast again. Man I love IT.. everything relates to everything.
-
Nope, it's already listed like the Captive portal. Captive portal won't work without kernel work, so that's end of the year at it's earliest.
Ipsec should work after some gui modifications.
I just wanted to play a bit with the captive portal. No real need to use it. I'll use WPA2-Enterprise on my DLink DIR655 in combination with the Microsoft Network Policy server in Windows 2008 R2 now which provides RADIUS authentication against Microsoft Active Directory. Allows logging in securely to your WLAN using your Windows domain credentials. Works like a charm. As said in an earlier post.. I'm a Microsoft man 8)
By the way, if there are more Microsoft fanatics out here who'd like to hook pfSense up to Microsoft Active Directory for authentication to i.e. the webGUI, I can confirm this to work correctly as well with the Network Policy Server in Windows 2008R2 configured as RADIUS server. Sweet!
I'll keep an eye on the gitsync updates for the IPSec update for IPv6. Would be lovely.
-
without link local addresses you can not connect to the dhcp server. What is most likely here is that I am missing a rule that allows access to the dhcp server.
Been watching my firewall log and figured I would make some rules to allow the link-local addresses… Looking up some of the ports, this is what I currently have on my LAN interface for firewall rules.. What do you guys think?
Edit: I change fe80::/1 to fe80::/10 in my rules and changed the DHCPv6 to udp only.. When I ran 'pfctl -sr', I see there are some DHCPv6 rules with the destination as the lan address.
-
I would like to note that I am open for donations to my Paypal account on seth.mos@dds.nl.
I'm coding the features I need for the company I work for first, but if anyone has something they want to see sooner there is always a opening for persuasion.
-
I have now received native IPv6 connectivity from my ISP.
I am using Link Aggregation on WAN interface. IPv4 works fine on LAGG interface but I have trouble configuring IPv6 on LAGG interface.
It seems that there is problem with setting IPv6 default route on LAGG interface, because Diagnostic->Routes shows this output under IPv6:default 2a01:260:XXXX::d UGS 0 2937 1500 em0
For IPv4 it shows this
default 89.212.0.1 UGS 0 663297 1500 lagg0
So I assume that under IPv6 default route, interface should also be lagg0, not em0?
-
Yes, that should also have been lagg0. Since I don't have anything here that's lagg capable I'd need to search. What's odd though is that the default route path for v4 and v6 is exactly the same.
I can only guess that the parent interface in another piece of code is used causing it to fail. Hmmm. Can you send me a sanitized config.xml to my email address seth.mos@dds.nl
That's probably the only way to find out. You can safely strip the aliases and rules. I won't need a password as I'll just reset that. How many interfaces is this box?
-
Email with details sent!