25 May
2017
25 May
'17
7:45 p.m.
It looks to me like the new amprgw is working. I'd like to ask
for a brave volunteer who is willing to try changing his outgoing
route from old amprgw (169.228.66.251) to new amprgw (169.228.34.84)
to see if he's able to make connection with the outside world.
The return path will still be via old amprgw as we haven't changed
the nexthop for 44.0.0.0/8 from oldamprgw to new.
If someone would try this and let me know if it worked I'd very
much appreciate it.
- Brian
25 May
25 May
7:50 p.m.
Brian,
I'm willing to reseed my default scripts with the new IP and reboot.
- SEED IPSET RULE
- DYNAMIC SCRIPT RULE
Does this mean I'd be receiving routes from 169.228.34.84?
Let me know when to proceed.
- KB3VWG
Lynwood
7:56 p.m.
No, I do not have the rip sender enabled on new amprgw to avoid
causing routing flaps.
You may proceed when ... ah, I see you have already. Is it
working?
- Brian
On Thu, May 25, 2017 at 07:50:06PM -0400, lleachii--- via 44Net wrote:
Brian,
I'm willing to reseed my default scripts with the new IP and reboot.
- SEED IPSET RULE
- DYNAMIC SCRIPT RULE
Does this mean I'd be receiving routes from 169.228.34.84?
Let me know when to proceed.
- KB3VWG
Lynwood
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
7:58 p.m.
Brian,
With default route changed:
Trace Output:
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 kb3vwg-001.ampr.org (44.60.44.1) 1.004 ms 0.988 ms 1.128 ms
2 amprgw.ucsd.edu (169.228.34.84) 68.894 ms 68.891 ms 68.883 ms
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
done ...
- KB3VWG
7:59 p.m.
Just to be clear, did that work BEFORE you changed the default route?
- Brian
On Thu, May 25, 2017 at 07:58:08PM -0400, lleachii--- via 44Net wrote:
(Please trim inclusions from previous messages)
_______________________________________________
Brian,
With default route changed:
Trace Output:
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 kb3vwg-001.ampr.org (44.60.44.1) 1.004 ms 0.988 ms 1.128 ms
2 amprgw.ucsd.edu (169.228.34.84) 68.894 ms 68.891 ms 68.883 ms
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
done ...
- KB3VWG
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
8:05 p.m.
Lynwood, what I see happening is your IPIP packets coming in,
and decapped traffic going out:
17:03:08.012996 IP (tos 0x0, ttl 62, id 62733, offset 0, flags [none], proto UDP (17),
length 63, bad cksum 0 (->c529)!)
44.60.44.3.41269 > 208.80.153.231.53: 53665 A? www.mediawiki.org. (35)
They all seem to be queries to DNS servers. Are you getting any
responses?
- Brian
8:24 p.m.
On Thu, May 25, 2017 at 08:21:51PM -0400, lleachii--- via 44Net wrote:
Booting up and commencing testing from 44.60.44.14.
- KB3VWG
Ok, I'm seeing pings from that address. Are you getting responses?
17:22:56.609480 IP (tos 0x0, ttl 1, id 60499, offset 0, flags [none], proto ICMP (1),
length 64, bad cksum 0 (->740d)!)
44.60.44.14 > 149.174.107.100: ICMP echo request, id 17157, seq 60032, length 44
17:22:56.710082 IP (tos 0x0, ttl 2, id 60514, offset 0, flags [none], proto ICMP (1),
length 64, bad cksum 0 (->72fe)!)
44.60.44.14 > 149.174.107.100: ICMP echo request, id 17157, seq 60288, length 44
17:22:56.808823 IP (tos 0x0, ttl 3, id 60527, offset 0, flags [none], proto ICMP (1),
length 64, bad cksum 0 (->71f1)!)
44.60.44.14 > 149.174.107.100: ICMP echo request, id 17157, seq 60544, length 44
17:22:56.910122 IP (tos 0x0, ttl 4, id 60533, offset 0, flags [none], proto ICMP (1),
length 64, bad cksum 0 (->70eb)!)
44.60.44.14 > 149.174.107.100: ICMP echo request, id 17157, seq 60800, length 44
17:22:57.010197 IP (tos 0x0, ttl 5, id 60552, offset 0, flags [none], proto ICMP (1),
length 64, bad cksum 0 (->6fd8)!)
44.60.44.14 > 149.174.107.100: ICMP echo request, id 17157, seq 61056, length 44
17:22:57.112605 IP (tos 0x0, ttl 6, id 60562, offset 0, flags [none], proto ICMP (1),
length 64, bad cksum 0 (->6ece)!)
44.60.44.14 > 149.174.107.100: ICMP echo request, id 17157, seq 61312, length 44
17:22:57.490092 IP (tos 0x0, ttl 1, id 60606, offset 0, flags [none], proto ICMP (1),
length 64, bad cksum 0 (->73a2)!)
44.60.44.14 > 149.174.107.100: ICMP echo request, id 17157, seq 62080, length 44
17:22:57.611330 IP (tos 0x0, ttl 2, id 60616, offset 0, flags [none], proto ICMP (1),
length 64, bad cksum 0 (->7298)!)
44.60.44.14 > 149.174.107.100: ICMP echo request, id 17157, seq 62336, length 44
9:12 p.m.
On Thu, May 25, 2017 at 09:02:48PM -0400, lleachii--- via 44Net wrote:
No.
I don't know that you are getting responses. That's what I asked you.
I see the packets going out and I have no way to see them coming back
in, so I was asking if you were getting responses to your pings.
But there's something really strange going on with your host 44.60.44.14.
You are pinging 8.8.8.8 in a normal manner, but you are ALSO pinging
4.2.2.2 with extremely small TTLs. For every ping you send to 8.8.8.8,
you also send 6 more to 4.2.2.2 with TTLs that vary from 1 to 6.
Look:
18:07:08.653712 IP (tos 0x0, ttl 62, id 7509, offset 0, flags [DF], proto ICMP (1), length
84, bad cksum 0 (->b6fa)!)
44.60.44.14 > 8.8.8.8: ICMP echo request, id 1348, seq 2633, length 64
18:07:08.893364 IP (tos 0x0, ttl 1, id 18551, offset 0, flags [none], proto ICMP (1),
length 64, bad cksum 0 (->12f9)!)
44.60.44.14 > 4.2.2.2: ICMP echo request, id 21509, seq 56017, length 44
18:07:09.018946 IP (tos 0x0, ttl 2, id 18565, offset 0, flags [none], proto ICMP (1),
length 64, bad cksum 0 (->11eb)!)
44.60.44.14 > 4.2.2.2: ICMP echo request, id 21509, seq 56273, length 44
18:07:09.144229 IP (tos 0x0, ttl 3, id 18581, offset 0, flags [none], proto ICMP (1),
length 64, bad cksum 0 (->10db)!)
44.60.44.14 > 4.2.2.2: ICMP echo request, id 21509, seq 56529, length 44
18:07:09.269366 IP (tos 0x0, ttl 4, id 18601, offset 0, flags [none], proto ICMP (1),
length 64, bad cksum 0 (->fc7)!)
44.60.44.14 > 4.2.2.2: ICMP echo request, id 21509, seq 56785, length 44
18:07:09.395117 IP (tos 0x0, ttl 5, id 18627, offset 0, flags [none], proto ICMP (1),
length 64, bad cksum 0 (->ead)!)
44.60.44.14 > 4.2.2.2: ICMP echo request, id 21509, seq 57041, length 44
18:07:09.520412 IP (tos 0x0, ttl 6, id 18648, offset 0, flags [none], proto ICMP (1),
length 64, bad cksum 0 (->d98)!)
44.60.44.14 > 4.2.2.2: ICMP echo request, id 21509, seq 57297, length 44
What are you doing?
- Brian
Are you getting responses?
Where are my
responses coming from?
(maybe is connection tracking.....(via Rob's "MAC" known to the
Kernel...").
Only thing I can think of...
- KB3VWG
9:13 p.m.
Brian,
Are you mirroring the ports or something?
How are u trying to send packet to me with Old_AMPRGW up?
- KB3VWG
9:19 p.m.
On Thu, May 25, 2017 at 09:13:10PM -0400, lleachii--- via 44Net wrote:
Brian,
Are you mirroring the ports or something?
How are u trying to send packet to me with Old_AMPRGW up?
- KB3VWG
I'm not trying to send packets to you.
What I wanted to know was whether responses to the pings you were
sending out via new amprgw were coming back to you. The would have
come through old amprgw, because that's still the route to you.
Did you leave the inbound path to your system via old amprgw open
or was it automatically firewalled out when you changed to using
new amprgw for your outbound?
- Brian
9:27 p.m.
Brian,
I seeded both IPs...and you said they were in my last Encap.
Send me your SRC IP off thread, you and I can browse my netflow.
I'm not blocking
The would have
come through old amprgw
root@router:~# ip route get 44.0.0.1 from 44.60.44.1
44.0.0.1 from 44.60.44.1 via 169.228.66.251 dev tunl0 table 44
cache window 840
root@router:~# ip route get 44.128.0.1 from 44.60.44.1
44.128.0.1 from 44.60.44.1 via 169.228.34.84 dev tunl0 table 44
cache window 84
root@router:~# ipset test ipipfilter 169.228.34.84
169.228.34.84 is in set ipipfilter
root@router:~# ipset test ipipfilter 169.228.66.251
169.228.66.251 is in set ipipfilter
It's still in my firewall.
No "inbound path". tunl0 is open and connection tracking is off.
- KB3VWG
9:45 p.m.
On Thu, May 25, 2017 at 09:27:44PM -0400, lleachii--- via 44Net wrote:
(Please trim inclusions from previous messages)
_______________________________________________
Brian,
I seeded both IPs...and you said they were in my last Encap.
I have no idea what you mean by 'seeded'.
Send me your SRC IP off thread, you and I can browse
my netflow.
I AM NOT PINGING OR SENDING TO YOU.
No "inbound path". tunl0 is open and
connection tracking is off.
Well, if there's no inbound path, then you're not going to see
ping replies, are you?
- Brian
8:06 p.m.
Brian,
Yes:
Trace Output:
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 kb3vwg-001.ampr.org (44.60.44.1) 3.122 ms 3.147 ms 3.463 ms
2 amprgw.sysnet.ucsd.edu (169.228.66.251) 70.000 ms 70.117 ms 70.358 ms
3 ebu-3b-720-vl441-cse-sysnet-gw-222-1.ucsd.edu (137.110.222.1) 71.039 ms 71.182 ms
71.967 ms
4 ebu3b-6509-nodem-core-interconnect-vl910-gw-255-130.ucsd.edu (132.239.255.130)
71.586 ms 71.733 ms 72.567 ms
5 mx0--nodem-core-30ge.ucsd.edu (132.239.254.162) 73.147 ms 73.233 ms 73.333 ms
6 dc-sdg-agg4--ucsd-1.cenic.net (137.164.23.53) 73.347 ms 67.595 ms 67.688 ms
7 dc-tus-agg3--sdg-agg4-100ge.cenic.net (137.164.11.8) 69.465 ms 69.459 ms 69.561
ms
8 dc-lax-agg6--tus-agg3-100ge.cenic.net (137.164.11.6) 71.133 ms 71.137 ms 71.130
ms
9 74.125.49.165 (74.125.49.165) 71.513 ms 71.500 ms 71.560 ms
10 108.170.247.161 (108.170.247.161) 72.029 ms 108.170.247.225 (108.170.247.225)
72.139 ms 72.327 ms
11 66.249.94.253 (66.249.94.253) 72.862 ms 216.239.62.79 (216.239.62.79) 73.197 ms
72.14.236.69 (72.14.236.69) 73.302 ms
12 * google-public-dns-a.google.com (8.8.8.8) 70.032 ms 69.993 ms
done ...
I'm going to seed both IP to the startup IPSET when rebooting back to
the New_AMPRGW.
- KB3VWG
2737
days inactive
2738
days old
17 comments
2 participants
participants (2)
-
Brian Kantor -
lleachii＠aol.com