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
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
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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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
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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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
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
On Thu, May 25, 2017 at 09:02:48PM -0400, lleachii--- via 44Net wrote:
No.
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
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
Brian,
Are you mirroring the ports or something?
How are u trying to send packet to me with Old_AMPRGW up?
- KB3VWG
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
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
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
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
-
Brian Kantor -
lleachii＠aol.com