Print

[PGNet]

Hi,

I've a /29 allocated from my ISP, x.x.x.100 - x.x.x.107.

I've created IPv6 tunnels for four of the IPs, and am trying to set the IPv4 endpoints @ Tunnelbroker.

I've opened my firewall top pings from 66.220.2.74.

For 3 of the tunnels, I can set endpoints of

   x.x.x.101
   x.x.x.103
   x.x.x.106

and all's OK.

For the 4th, @

   x.x.x.104

setting the IP4 endpoint fails, reporting,

   Error: Your IPv4 endpoint is unreachable or unstable
   Your IPv4 endpoint must be pingable. If you are blocking ICMP, please allow 66.220.2.74 through your firewall.

These IPs are all on the same /29, on the same DSL twisted-pair; I'm not clear how/why three can be stable/OK, and one's not ...

Any suggestions?

Thanks.

[kriteknetworks]

Firewall on said IP?

[broquea]

Like I mentioned in your ticket, our server cannot ping that one IP. When we traced, it looked like the .104 was routed behind .106 (trace went to .106 then started timing out afterwards).

Also, .102 and .105, when traced to, also appear to be behind .106

Also for a /29 breakdown, with a .100 netblock, wouldn't the ISP be providing gateway on ".101" and then your usable would be .102-106?

[PGNet]

Hi,

Like I mentioned in your ticket,

Yes, thanks for the reply, and checking the real IPs.  That done, I'll keep the follow-up here.

our server cannot ping that one IP. When we traced, it looked like the .104 was routed behind .106 (trace went to .106 then started timing out afterwards).

Also, .102 and .105, when traced to, also appear to be behind .106

I'm not clear as to WHY that's occurring; and, tbh, not even certain what the 'routed behind' means/implies.  I've had servers behind those IPs for ages that've behaved themselves.  Given you comment, that, too, may've been simply fortuitous :-/

Also for a /29 breakdown, with a .100 netblock, wouldn't the ISP be providing gateway on ".101" and then your usable would be .102-106?

Not sure that it matters, but the IPs should be ".2xx" (Copy-n-paste typos ...)

Anyway, here's what the ISP says I have

   x.x.x.207 BROADCAST, programmed in RedBack
   x.x.x.206 WAN Interface / Gateway, public/routeable
   x.x.x.205 public/routeable
   x.x.x.204 public/routeable
   x.x.x.203 public/routeable
   x.x.x.202 public/routeable
   x.x.x.201 public/routeable
   x.x.x.200 NETWORK, programmed in RedBack

and that 201-206 are 'usable'.

Currently, my network's IP (e.g, browsing to external sites) reports as x.x.x.206.

So, iiuc, and I may not, tunnels @

   x.x.x.201
   x.x.x.203
   x.x.x.206

and the errant,

   x.x.x.204

are all at "usable" IPs.  In any case, there "should" be no functional/configuration difference between .204 & .203, yet the former fails and the latter works.


Given the coments, I suspect it's likely I've something fundamentally 'wrong' in the fw -- but, if so, I'm unclear as to what, especially given that "everything else" has been working, and what may be unique about the Tunnelborker ping-test that differentiates between the two.

Help & comments are appreciated.

Thanks.

[PGNet]

One more bit of information ... relevant, or not, I don't know.

I just recently migrated to a NEW ip range.  I.e., from A.A.A.##/29 to X.X.X.##/29.

Nothing's changed at my site OTHER than those real, WAN-side IPs.  FW conf, e.g., remains exactly the same as it was before.

That said, in the former A.A.A.## setup, the four tunnels were set up with no errors for the four corresponding IPv4 endpoints.

In the new range, I'm simply trying to switch the tunnels from the 'old' to 'new' IPv4 endpoints.

[PGNet]

Firewall on said IP?

currently Freebsd+PF.

for debugging, early in my PF firewall, i've set:

  pass log quick inet proto icmp from 66.220.2.74 to any icmp-type { echoreq, unreach } keep state
  pass log quick inet proto icmp from any to 66.220.2.74 icmp-type { echoreq, unreach } keep state

then @ the Tunnelbroker site, i've submitted the x.x.x.204 endpoint for the existing tunnel.  as before, it fails with:

   Error: Your IPv4 endpoint is unreachable or unstable
   Your IPv4 endpoint must be pingable. If you are blocking ICMP, please allow 66.220.2.74 through your firewall.

and, during the process,

   tcpdump -vvvfi tun0 host 66.220.2.74

returns,

   tcpdump: listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes
   13:18:23.536529 IP (tos 0x0, ttl 58, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 66.220.2.74 > x.x.x.204: ICMP echo request, id 56166, seq 1, length 64
   13:18:23.537100 IP (tos 0x0, ttl 57, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 66.220.2.74 > x.x.x.204: ICMP echo request, id 56166, seq 1, length 64
   13:18:24.540509 IP (tos 0x0, ttl 58, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 66.220.2.74 > x.x.x.204: ICMP echo request, id 56166, seq 2, length 64
   13:18:24.540778 IP (tos 0x0, ttl 57, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 66.220.2.74 > x.x.x.204: ICMP echo request, id 56166, seq 2, length 64
   13:18:25.542489 IP (tos 0x0, ttl 58, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 66.220.2.74 > x.x.x.204: ICMP echo request, id 56166, seq 3, length 64
   13:18:25.542757 IP (tos 0x0, ttl 57, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 66.220.2.74 > x.x.x.204: ICMP echo request, id 56166, seq 3, length 64


and, also,

   tcpdump -vvv -tttt -nei pflog0

returns,

   2008-10-29 13:06:08.802172 rule 5/0(match): pass in on tun0: (tos 0x0, ttl 58, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 66.220.2.74 > x.x.x.204: ICMP echo request, id 18020, seq 1, length 64
   2008-10-29 13:06:08.802430 rule 5/0(match): pass out on tun0: (tos 0x0, ttl 57, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 66.220.2.74 > x.x.x.204: ICMP echo request, id 18020, seq 1, length 64