Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[v6]

Hi PacketTracer

Once again - thank you for your help!

Regarding DMZ there are different definitions on what it is, but the definition here http://en.wikipedia.org/wiki/DMZ_(computing) goes fine hand in hand with your description. And yes I agree.

(Regarding /127: Yes, you are right. I was at the time trying to experiment if it was possible to bind a virtual IPv6 address to the ISP-router and connect that to the WAN side of the 860L/CPE to get in compliance with RFC-6164. Besides the /127 problem in pfSense, it seems only possible if I had an extra NIC (which I do not have) or better a virtual interface in the ISP router (which feature it does not have to my knowledge).)

Regarding "communication relationships": Yes, that is what I want. :-)


Reachability test CPE LAN --> WAN (ISP LAN):
Precondition:
1) CPE fw off & no simple security.
2) IPv6 connectivity to the Internet
Test:
I did ping6 (icmpv6 echoes) and rltraceroute6 (UDP), tcptraceroute6 (TCP) and tracert6 (IMCPv6 Echo) from my desktop machine behind the LAN of my CPE/860L towards 2a02:188:4401::6.
Result:
I only reach 2a02:188:4401:8100::1 with the *traceroute6 programs - never the actual target. ping6 no success.

Reachability test WAN (ISP LAN) --> CPE LAN/my desktop computer (2a02:188:4401:8100:1337:1337:1337:1337)
Precondition:
1) CPE fw off & no simple security.
2) IPv6 connectivity to the Internet
Test:
I did ping6 (icmpv6 echoes) and traceroute6 (UDP/ICMP <-- http://www.freebsd.org/cgi/man.cgi?query=traceroute6&apropos=0&sektion=0&manpath=FreeBSD+8.3-RELEASE&arch=i386&format=html ) from the ISP router (2a02:188:4401::1) towards my LAN of my CPE/860L with target my desktop machine (2a02:188:4401:8100:1337:1337:1337:1337).
Result:
ping6 succeeds
traceroute6 UDP succeeds
traceroute6 ICMP succeeds

Reachability test DMZ Server (2a02:188:4401::6) --> CPE LAN/my desktop computer (2a02:188:4401:8100:1337:1337:1337:1337):
Precondition:
1) CPE fw off & no simple security.
2) IPv6 connectivity to the Internet
3) DMZ server has gateway set to 2a02:188:4401::1.
Test:
I did ping6 (icmpv6 echoes) and rltraceroute6 (UDP), tcptraceroute6 (TCP) and tracert6 (IMCPv6 Echo) from the ISP DMZ server towards the LAN of my CPE/860L.
Result:
ping6 (ICMPv6) fails. 2a02:188:4401:8100:1337:1337:1337:1337(2a02:188:4401:8100:1337:1337:1337:1337) 56 data bytes
tracert6 (ICMPv6) fails. Never reaches anything.
rltraceroute6 (UDP) fails. -"-
tcptraceroute6 (TCP) fails. -"-

Clients of the WAN can ping eachother and the ISP router without a problem
From within the DIR-860L I can ping e.g. 2a02:188:4401::6. I have added an image of this to this post.


Some selected IPv6 routes from the ISP router:

Code: [Select]

Destination            Gateway            Flags Refs Use    Mtu    Netif Expire
default                2a02:188:130:2::1 UGS    0    3012 1500 rl0
::1                    ::1                UH    0    0    16384 lo0
2a02:188:130:2::/64    link#4            U    0    96855 1500 rl0
2a02:188:130:2::2    link#4            UHS    0    0    16384 lo0
2a02:188:4401::/64    link#1            U    0    89921 1500 fxp0
2a02:188:4401::1    link#1            UHS    0    174    16384 lo0
2a02:188:4401:8100::/56 2a02:188:4401::8100 UGS    0    8525 1500 fxp0

Regarding the DIR-860L firewall: Protocol now has ALL instead of ANY.
Source start address has to differ from destination start address else a javascript popup window poped up. I circumvented this by choosing a destination start address that was within range of LAN, WAN, INTERNET (seen from CPE) meaning 1000:: to ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

Regarding activating firewall rules I had some strange experiences.
It seemed that everytime I switched "Turn IPv6 Filtering ON and ALLOW rules listed" (and the check boxes is selected ;-) ) and regardless of Simple Security is on or not the result is that Status - Logs - Router Status (radio button) gets filled with the firewall dropping my traffic. E.g. it drops if I go to ANY address that needs to pass either WAN or INTERNET e.g. http://[2a02:188:4401::6]/ (yeah a webserver as well) :-) or http://test-ipv6.com/

If I however choose "Turn IPv6 Filtering ON and DENY rules listed" then (also regardless of Simple Security is on or not) suddenly I have access to http://test-ipv6.com/ but still not e.g. http://[2a02:188:4401::6]/

I did try your settings (less network scope for AllowISPIn), but that did not make a change in the outcome.

I have added an image to this post about my fw settings. It has DENY rules listed set but the address ranges, interfaces and protocol applies to my test situation with "ALLOW rules listed".

[v6]

Forgot to mention a test from my VPS in Italy.

Test: target 2a02:188:4401:8100:1337:1337:1337:1337 from my VPS in Italy
Preconditions: like the other tests
Test: I tested with ping6, rltraceroute6 (UDP), tcptraceroute6 (TCP), tracert6 (ICMPv6 echo)
Results:
ping6 succeeds
rltraceroute6 only reaches 2a02:188:4401::8100 - so kind of fail.
tcptraceroute6 only reaches 2a02:188:130:2::2 - fail!
tracert6 succeeds

Comment: Regarding the *traceroute6 results it might be because 2a02:188:4401::8100 does not have inbound traffic allowed (from the Internet) in the ISP router. I will try to fix that and make a new test.
I have however a meeting I must attend to in about one hour from now, but I will make a new post.

[v6]

Here comes a follow-up to my last post regarding testing from my VPS in Italy and towards 2a02:188:4401:8100:1337:1337:1337:1337.

To make sure that nothing blocks this test I made 2a02:188:4401::8100 and 2a02:188:4401::1 publicly available to inbound traffic coming from the Internet.

This made one change.
Now the result is:
tcptraceroute6 - fails!
rltraceroute6 succeeds
tracert6 succeeds
ping6 succeeds

Meaning that tcptraceroute6 still fails under the same preconditions as the other tests.
I do not know why, but to compensate I tried to make a ssh test from my VPS in Italy to 2a02:188:4401:8100:1337:1337:1337:1337 and that worked!

So I will conclude at least the Internet connection also works from outside my ISP and into my LAN.

So what is left is the routing part which (I guess) does not work. Is it pfSense that does not know how to route within the LAN (DMZ/WAN of CPE/DIR-860L) when one of its clients contacts it or has it something to do with e.g. the DIR-860L routing/routing table?!?

The only thing that comes to my mind is to probe the network with e.g. WireShark at select points in the DMZ/WAN and see where possible icmp data floats around and make some packet captures and trace.

Do you have any suggestions - also regarding the firewall test I made in the CPE/DIR-860L?

Thanks once again PacketTracer! :-)

[PacketTracer]

Hi v6,

Reachability test DMZ Server (2a02:188:4401::6) --> CPE LAN/my desktop computer (2a02:188:4401:8100:1337:1337:1337:1337):
Precondition:
1) CPE fw off & no simple security.
2) IPv6 connectivity to the Internet
3) DMZ server has gateway set to 2a02:188:4401::1.
Test:
I did ping6 (icmpv6 echoes) and rltraceroute6 (UDP), tcptraceroute6 (TCP) and tracert6 (IMCPv6 Echo) from the ISP DMZ server towards the LAN of my CPE/860L.
Result:
ping6 (ICMPv6) fails. 2a02:188:4401:8100:1337:1337:1337:1337(2a02:188:4401:8100:1337:1337:1337:1337) 56 data bytes
tracert6 (ICMPv6) fails. Never reaches anything.
rltraceroute6 (UDP) fails. -"-
tcptraceroute6 (TCP) fails. -"-

This is interesting: tracert6 (ICMPv6) fails. Never reaches anything.

You should see at least that 2a02:188:4401::1 is reached, because due to "3) DMZ server has gateway set to 2a02:188:4401::1." the packet will be sent to your ISP router first.

If your ISP router (for some unknown reason, maybe via some policy) will not forward packets coming from WAN network back through this network (sort of "bouncing"), this would completely explain your observed negative results (First negative case: Reply packets from 2a02:188:4401::6 will not be routed back by your ISP router towards 2a02:188:4401:8100:1337:1337:1337:1337. Second negative case: Request packets from 2a02:188:4401::6 will not be forwarded by your ISP router towards 2a02:188:4401:8100:1337:1337:1337:1337). Just a theory ...

PacketTracer

EDIT

You could configure a route for 2a02:188:4401:8100::/56 next hop 2a02:188:4401::8100 within your DMZ host 2a02:188:4401::6. This would circumvent your ISP router. Check if connectivity tests 2a02:188:4401:8100:1337:1337:1337:1337 <--> 2a02:188:4401::6 will work with this

[v6]

I made a mistake. Sorry! I had added the new gateway on the DMZ server to a configuration file, but forgot that there was an existing route to the old /48 network, so I made a quick reboot just to be absolutely sure! Then the results where somewhat different:

So the results are:
Reachability test DMZ Server (2a02:188:4401::6) --> CPE LAN/my desktop computer (2a02:188:4401:8100:1337:1337:1337:1337):
Precondition:
1) CPE fw off & no simple security.
2) IPv6 connectivity to the Internet
3) DMZ server has gateway set to 2a02:188:4401::1.
4) No old routes ;-)
Test:
I did ping6 (icmpv6 echoes) and rltraceroute6 (UDP), tcptraceroute6 (TCP) and tracert6 (IMCPv6 Echo) from the ISP DMZ server towards the LAN of my CPE/860L.
Result:
ping6 (ICMPv6) succeeds! Hip Hip Hurray :-)
tracert6 (ICMPv6) succeeds!
rltraceroute6 (UDP) succeeds!
tcptraceroute6 (TCP) router.bjoernemosen.dk (2a02:188:4401::1)  0.289 ms  * * - fails! but it does not matter ;-)
ssh succeeds!

Reachability test CPE LAN desktop machine --> WAN (ISP LAN) DMZ server:
To make it quick: It works!

So... ehm... It works. A little embarrassing - a forgotten route on the DMZ server.
Thank you!
And you know what! Now there is a solution described for everyone else having the same sort of network/problem:
Add a route (and no need to adjust ipv6 firewall settings as it seems on the CPE.)

Please tell me if you would like something for your help! E.g. if I can order you some beer or chocolates e.g. from a local web store near you. PM me your address in that case.  :-)

[PacketTracer]

Hi v6,

looking at ...

Besides that I have something else I have to investigate more because I am not totally sure about it yet: The pfSense LAN DHCP-PD functionality seems to be broken. It does not create routes on the fly (if it was intended to be that way) neither it seems to "link" a wan ip given to the CPE with the correct /56 network - if a route was created manually in advance by the netadministrator. (But I have to test it more thoroughly.)

... there is still some homework left to do for you. Good luck!

tcptraceroute6 (TCP) router.bjoernemosen.dk (2a02:188:4401::1)  0.289 ms  * * - fails! but it does not matter ;-)

...

Please tell me if you would like something for your help! E.g. if I can order you some beer or chocolates e.g. from a local web store near you. PM me your address in that case.  :-)

Nice 28 houses at Bjørnemosen (watched them following the Google Streetview link on your website). Instead of drinking beer or eating chocolate I'd prefer spending my next holidays there!

 

PacketTracer

[v6]

Thank you
You shall be welcome!

And yes you are right about DHCP-PD.
It is going to be interesting if I can get it to work.
I will try to google for info about how it is supposed to work e.g. in setup guides and in other products so that I get an idea about how it actually should work regarding routing.
(To add to that I am still waiting for the book about pfSense 2.1 to be released. There should be about 200 additional pages compared to the old book.)
Should it turn out that pfSense does not have the kind of DHCP-PD support I need (regarding dynamically adding a route as long as the DHCP-PD lease is still valid) then
_maybe_ if I am able to understand the code of pfSense I suppose I could try to make a (little?) patch where the netadmin has an option he could click to enable that sort of support.

[PacketTracer]

... this case of IPv6 firewall failure has been added as case [4] to a list of other cases, see here.

PT