SixXS::Sunset 2017-06-06

Ticket ID: SIXXS #3310465
Ticket Status: Resolved

PoP: dkcph01 - Availo (Copenhagen)

Tunnel does not work after move to new IPv4 endpoint
[dk] Shadow Hawkins on Sunday, 02 January 2011 07:28:10
TunnelT19015 IPv6 Prefix2001:16d8:dd00:36::1/64 PoP IPv62001:16d8:dd00:36::1 Your IPv62001:16d8:dd00:36::2 IPv4 endpoint moved from 90.184.149.175 to 95.166.183.200 on december 29th 2010 The move was due to new DSL line and modem. Different product, but same provider - Fullrate. IPv4 endpoint is a Juniper SRX100 that has been properly reconfigured with the new address. I can verify that I am sending packets via the tunnel when trying to ping the POP IPv6 address, but I get no reply. There are also no tunneled packets incoming when I do ping from an IPv6 server on another tunnel. IPv4 ping from SRX to POP works fine Tunnel is currently disabled to avoid credit-countdown and info mails. Could you please verify that the tunnel has been properly reconfigured in the POP?
State change: remoteproblem Locked
[ch] Jeroen Massar SixXS Staff on Wednesday, 05 January 2011 12:41:37
Message is Locked
The state of this ticket has been changed to remoteproblem
Tunnel does not work after move to new IPv4 endpoint
[ch] Jeroen Massar SixXS Staff on Wednesday, 05 January 2011 12:41:55
When you disable a tunnel, it won't work of course.
Tunnel does not work after move to new IPv4 endpoint
[dk] Shadow Hawkins on Wednesday, 05 January 2011 17:27:52
Enabled again (I assumed you would do that when troubleshooting - my bad) Still no connectivity.
Tunnel does not work after move to new IPv4 endpoint
[ch] Jeroen Massar SixXS Staff on Thursday, 06 January 2011 16:12:43
PoP side is fully up and functional, nothing that I can see that can be wrong there. 64 bytes from 2001:16d8:dd00:36::1: icmp_seq=1 ttl=60 time=14.0 ms Your host seems to be completely unresponsive (not even an ICMP) for protocol 41. Really can't help you there.
Tunnel does not work after move to new IPv4 endpoint
[dk] Shadow Hawkins on Wednesday, 26 January 2011 01:31:30
Traceroute from my firewall: lle@bouncer> traceroute dkcph01.sixxs.net inet no-resolve source 95.166.183.200 traceroute to dkcph01.sixxs.net (93.158.77.42) from 95.166.183.200, 30 hops max, 40 byte packets 1 95.166.183.1 10.147 ms 9.787 ms 7.686 ms 2 90.185.4.5 15.590 ms 7.290 ms 7.609 ms 3 90.185.7.77 15.136 ms 8.295 ms 15.082 ms 4 87.54.42.85 8.345 ms 7.701 ms 9.107 ms 5 88.131.143.112 8.329 ms 9.287 ms 9.117 ms 6 88.131.143.112 8.257 ms 14.413 ms 8.892 ms 7 195.69.117.143 9.220 ms 9.257 ms 8.697 ms 8 82.96.1.26 9.528 ms 9.508 ms 9.311 ms 9 93.158.77.42 16.572 ms 9.830 ms 9.760 ms tcpdump from my firewall while a ping is running from another sixxs tunnel (2a01:4f8:131:23a1::2) towards my IPv6 2001:16d8:dd00:36::2 01:16:00.415262 In IP (tos 0x0, ttl 58, id 0, offset 0, flags [DF], proto: IPv6 (41), length: 124) 93.158.77.42 > 95.166.183.200: IP6 (hlim 49, next-header: ICMPv6 (58), length: 64) 2a01:4f8:131:23a1::2 > 2001:16d8:dd00:36::2: [icmp6 sum ok] ICMP6, echo request, seq 6565 01:16:00.415470 Out IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: IPv6 (41), length: 124) 95.166.183.200 > 93.158.77.42: IP6 (hlim 64, next-header: ICMPv6 (58), length: 64) 2001:16d8:dd00:36::2 > 2a01:4f8:131:23a1::2: [icmp6 sum ok] ICMP6, echo reply, seq 6565 01:16:01.415525 In IP (tos 0x0, ttl 58, id 0, offset 0, flags [DF], proto: IPv6 (41), length: 124) 93.158.77.42 > 95.166.183.200: IP6 (hlim 49, next-header: ICMPv6 (58), length: 64) 2a01:4f8:131:23a1::2 > 2001:16d8:dd00:36::2: [icmp6 sum ok] ICMP6, echo request, seq 6566 01:16:01.415779 Out IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: IPv6 (41), length: 124) 95.166.183.200 > 93.158.77.42: IP6 (hlim 64, next-header: ICMPv6 (58), length: 64) 2001:16d8:dd00:36::2 > 2a01:4f8:131:23a1::2: [icmp6 sum ok] ICMP6, echo reply, seq 6566 01:16:02.415331 In IP (tos 0x0, ttl 58, id 0, offset 0, flags [DF], proto: IPv6 (41), length: 124) 93.158.77.42 > 95.166.183.200: IP6 (hlim 49, next-header: ICMPv6 (58), length: 64) 2a01:4f8:131:23a1::2 > 2001:16d8:dd00:36::2: [icmp6 sum ok] ICMP6, echo request, seq 6567 01:16:02.415559 Out IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: IPv6 (41), length: 124) 95.166.183.200 > 93.158.77.42: IP6 (hlim 64, next-header: ICMPv6 (58), length: 64) 2001:16d8:dd00:36::2 > 2a01:4f8:131:23a1::2: [icmp6 sum ok] ICMP6, echo reply, seq 6567 And a more detailed view: 01:21:05.435333 In Juniper PCAP Flags [Ext, no-L2, In], PCAP Extension(s) total length 16 Device Media Type Extension TLV #3, length 1, value: Ethernet (1) Logical Interface Encapsulation Extension TLV #6, length 1, value: Ethernet (14) Device Interface Index Extension TLV #1, length 2, value: 34048 Logical Interface Index Extension TLV #4, length 4, value: 68 -----original packet----- PFE proto 2 (ipv4): (tos 0x0, ttl 58, id 0, offset 0, flags [DF], proto: IPv6 (41), length: 124) 93.158.77.42 > 95.166.183.200: (hlim 49, next-header: ICMPv6 (58), length: 64) 2a01:4f8:131:23a1::2 > 2001:16d8:dd00:36::2: [icmp6 sum ok] ICMP6, echo request, seq 6870 01:21:05.435541 Out Juniper PCAP Flags [Ext], PCAP Extension(s) total length 16 Device Media Type Extension TLV #3, length 1, value: Ethernet (1) Logical Interface Encapsulation Extension TLV #6, length 1, value: Ethernet (14) Device Interface Index Extension TLV #1, length 2, value: 34048 Logical Interface Index Extension TLV #4, length 4, value: 68 -----original packet----- 0:0:24:c5:ce:c9 > b0:c6:9a:60:7e:0, ethertype IPv4 (0x0800), length 138: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: IPv6 (41), length: 124) 95.166.183.200 > 93.158.77.42: (hlim 64, next-header: ICMPv6 (58), length: 64) 2001:16d8:dd00:36::2 > 2a01:4f8:131:23a1::2: [icmp6 sum ok] ICMP6, echo reply, seq 6870 IPv4 connectivity from POP to my end seems to be working - IPv6 gets to my end and I send out IPv6 in an encapsulated packet. My ISP tells me that it works fine from other DSL lines in their network. Could you please verify my configuration on dkcph01 again? I fear the configuration or tunnel might have gone bad or stale somehow when I moved IPv4 endpoint address. Feel free to re-configure the tunnel if thats what it takes. Thanks
Tunnel does not work after move to new IPv4 endpoint
[ch] Jeroen Massar SixXS Staff on Wednesday, 26 January 2011 14:28:23
lle@bouncer> traceroute dkcph01.sixxs.net inet no-resolve source 95.166.183.200
Why do you need to specify the source address there?
IPv4 connectivity from POP to my end seems to be working - IPv6 gets to my end and I send out IPv6 in an encapsulated packet.
But the PoP never gets a packet back, not even an ICMPv4 for stating unreachable. I suggest you check your firewall rules properly and also your routing tables.
Could you please verify my configuration on dkcph01 again?
I fear the configuration or tunnel might have gone bad or stale somehow
when I moved IPv4 endpoint address.
It is fine, it all checks out, don't worry, that really is not the issue. (unless black magic hit something somewhere, but that is not the case).
Tunnel does not work after move to new IPv4 endpoint
[dk] Shadow Hawkins on Monday, 07 February 2011 13:39:34
Issue resolved. My tunnel interface and interface to the DSL-CPE (with IPv4 on) are both on security zone "untrust". LAN is on "trust" The policy to allow traffic within the zone was missing. After adding the config below to my firewall traffic started flowing again. This also fits the view I had that the tunnel interface sent the encapsulated traffic, but you never received it (since it was blocked internally in the firewall) set security policies from-zone untrust to-zone untrust policy default-permit match source-address any set security policies from-zone untrust to-zone untrust policy default-permit match destination-address any set security policies from-zone untrust to-zone untrust policy default-permit match application any set security policies from-zone untrust to-zone untrust policy default-permit then permit Thank you for your support.
State change: resolved Locked
[ch] Jeroen Massar SixXS Staff on Monday, 07 February 2011 18:59:08
Message is Locked
The state of this ticket has been changed to resolved

Please note Posting is only allowed when you are logged in.

Static Sunset Edition of SixXS
©2001-2017 SixXS - IPv6 Deployment & Tunnel Broker