Hi,
I added a gateway to one of my servers and set up a packet capture system on it. It is running a webserver inside a container with the relevant gateway configuration. The prefix is using the "BGP routed subnets" configuration whereby the gateway is inside the prefix, but using a /31.
https://u4477715.ct.sendgrid.net/wf/click?upn=Ki4chJONuNfM0VomxEE-2BoZH6yGOE...
It should auto-detect the client IP and captures all packets to/from that address. If the client IP is within 44/8 then it will check the routing table for a gateway and if so include that IP as well. I am not sure if there would be concerns with allowing the user to type an IP address to capture to/from, given that it's a non-production gateway.
I have the subnet 44.131.14.252/31 registered on the portal with a gateway address of 44.131.14.253. 252 should send encapsulated packets and 253 should send directly. Both addresses are on the same host.
I have removed my previous route for 44.131.14.0/24 because nested gateways don't work properly. I have tested to several destinations and it seems to work, but if anyone finds something I've missed let me know!
If it works properly and is useful then a hostname under ampr.org might be more appropriate, but for now I’m just using a hostname under my domain.
Thanks, Mike, M6XCV
Hi Mike...doesnt work from here....
source should be 44.56.53.3 (NAT from internal network)
here is snippet of my routing table
242 ADr 44.131.11.0/29 44.0.0.1 120 243 ADr 44.131.14.128/26 44.0.0.1 120 244 ADr 44.131.14.252/31 44.131.14.253 120 245 ADr 44.131.35.128/29 44.0.0.1 120 246 ADr 44.131.56.0/29 44.0.0.1 120
C:>tracert 44.131.14.253
Tracing route to 44.131.14.253 over a maximum of 30 hops
1 <1 ms * <1 ms xtm520.wa4zlw.homedns.org [10.161.51.3] 2 1 ms 1 ms <1 ms core100.wa4zlw.ampr.org [44.56.53.1] 3 br0.core100.wa4zlw.homedns.org [10.4.0.2] reports: Destination host unreachable.
Trace complete.
C:>tracert 44.131.14.252
Tracing route to 44.131.14.252 over a maximum of 30 hops
1 <1 ms <1 ms * xtm520.wa4zlw.homedns.org [10.161.51.3] 2 2 ms <1 ms <1 ms core100.wa4zlw.ampr.org [44.56.53.1] 3 * * * Request timed out. 4 * * * Request timed out. 5 * * * Request timed out. 6 * * * Request timed out. 7 * * * Request timed out. 8 * * * Request timed out. 9 * * * Request timed out. 10 * * * Request timed out. 11 * * * Request timed out. 12 * * * Request timed out. 13 * * * Request timed out. 14 * * * Request timed out. 15 ^C C:>
Leon
On 5/8/2017 7:00 AM, M6XCV (Mike) wrote:
I have the subnet 44.131.14.252/31 registered on the portal with a gateway address of 44.131.14.253. 252 should send encapsulated packets and 253 should send directly. Both addresses are on the same host.
I have removed my previous route for 44.131.14.0/24 because nested gateways don't work properly. I have tested to several destinations and it seems to work, but if anyone finds something I've missed let me know!
Are you able to see the packets originating from your end?
I seem to be sending to that IP correctly, but get no reply.
https://u4477715.ct.sendgrid.net/wf/click?upn=MJaTQVDJZogYIZySndf7y-2BCWLgZM...
When I tested from 44.131.14.140, which is behind a non-44 gateway, I did get a reply. I did not get a reply from an Internet IP.
Thanks, Mike, M6XCV
On 8 May 2017 at 12:11, Leon Zetekoff wa4zlw@backwoodswireless.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hi Mike...doesnt work from here....
source should be 44.56.53.3 (NAT from internal network)
here is snippet of my routing table
242 ADr 44.131.11.0/29 44.0.0.1 120 243 ADr 44.131.14.128/26 44.0.0.1 120 244 ADr 44.131.14.252/31 44.131.14.253 120 245 ADr 44.131.35.128/29 44.0.0.1 120 246 ADr 44.131.56.0/29 44.0.0.1 120
C:>tracert 44.131.14.253
Tracing route to 44.131.14.253 over a maximum of 30 hops
1 <1 ms * <1 ms xtm520.wa4zlw.homedns.org [10.161.51.3] 2 1 ms 1 ms <1 ms core100.wa4zlw.ampr.org [44.56.53.1] 3 br0.core100.wa4zlw.homedns.org [10.4.0.2] reports: Destination host unreachable.
Trace complete.
C:>tracert 44.131.14.252
Tracing route to 44.131.14.252 over a maximum of 30 hops
1 <1 ms <1 ms * xtm520.wa4zlw.homedns.org [10.161.51.3] 2 2 ms <1 ms <1 ms core100.wa4zlw.ampr.org [44.56.53.1] 3 * * * Request timed out. 4 * * * Request timed out. 5 * * * Request timed out. 6 * * * Request timed out. 7 * * * Request timed out. 8 * * * Request timed out. 9 * * * Request timed out. 10 * * * Request timed out. 11 * * * Request timed out. 12 * * * Request timed out. 13 * * * Request timed out. 14 * * * Request timed out. 15 ^C C:>
Leon
Hi Mike...I haven't looked yet I am beta testing a grandstream device and that's taking my time, lets take this off-list. I was able to ping the 14.140 from the mikrotik not from inside since all 44 traffic goes to the mikrotik not my watchguard.
leon
On 5/8/2017 7:52 AM, M6XCV (Mike) wrote:
(Please trim inclusions from previous messages) _______________________________________________ Are you able to see the packets originating from your end?
I seem to be sending to that IP correctly, but get no reply.
https://u4477715.ct.sendgrid.net/wf/click?upn=MJaTQVDJZogYIZySndf7y-2BCWLgZM...
When I tested from 44.131.14.140, which is behind a non-44 gateway, I did get a reply. I did not get a reply from an Internet IP.
Thanks, Mike, M6XCV
On 8 May 2017 at 12:11, Leon Zetekoff wa4zlw@backwoodswireless.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hi Mike...doesnt work from here....
source should be 44.56.53.3 (NAT from internal network)
here is snippet of my routing table
242 ADr 44.131.11.0/29 44.0.0.1 120 243 ADr 44.131.14.128/26 44.0.0.1 120 244 ADr 44.131.14.252/31 44.131.14.253 120 245 ADr 44.131.35.128/29 44.0.0.1 120 246 ADr 44.131.56.0/29 44.0.0.1 120
C:>tracert 44.131.14.253
Tracing route to 44.131.14.253 over a maximum of 30 hops
1 <1 ms * <1 ms xtm520.wa4zlw.homedns.org [10.161.51.3] 2 1 ms 1 ms <1 ms core100.wa4zlw.ampr.org [44.56.53.1] 3 br0.core100.wa4zlw.homedns.org [10.4.0.2] reports: Destination host unreachable.
Trace complete.
C:>tracert 44.131.14.252
Tracing route to 44.131.14.252 over a maximum of 30 hops
1 <1 ms <1 ms * xtm520.wa4zlw.homedns.org [10.161.51.3] 2 2 ms <1 ms <1 ms core100.wa4zlw.ampr.org [44.56.53.1] 3 * * * Request timed out. 4 * * * Request timed out. 5 * * * Request timed out. 6 * * * Request timed out. 7 * * * Request timed out. 8 * * * Request timed out. 9 * * * Request timed out. 10 * * * Request timed out. 11 * * * Request timed out. 12 * * * Request timed out. 13 * * * Request timed out. 14 * * * Request timed out. 15 ^C C:>
Leon
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On Mon, May 08, 2017 at 07:11:36AM -0400, Leon Zetekoff wrote:
here is snippet of my routing table
242 ADr 44.131.11.0/29 44.0.0.1 120 243 ADr 44.131.14.128/26 44.0.0.1 120 244 ADr 44.131.14.252/31 44.131.14.253 120 245 ADr 44.131.35.128/29 44.0.0.1 120 246 ADr 44.131.56.0/29 44.0.0.1 120
If your path to 44.0.0.1 is via a tunnel, could it be that your packet is showing up at amprgw with both source and destination on tunneled subnets? If so, it will be discarded. - Brian
It seems any of the BGP sites I can not get to (?)
Others I can get to.
here's part of my routing table:
[admin@core100.wa4zlw.homedns.org] > ip route print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 A S ;;; Default UCSD reply route 0.0.0.0/0 ucsd-gw 250 1 ADC 44.0.0.0/8 44.56.53.1 ucsd-gw 0 226 ADr 44.129.31.0/24 44.0.0.1 120 227 ADr 44.129.128.0/24 44.0.0.1 120 228 ADr 44.130.0.0/16 44.0.0.1 120 229 ADr 44.130.119.0/24 44.130.121.2 120 230 ADr 44.130.121.0/24 44.130.121.2 120 231 ADr 44.130.122.0/23 44.130.122.2 120 232 ADr 44.130.124.0/22 44.130.124.2 120 233 ADr 44.130.224.0/28 44.0.0.1 120 242 ADr 44.131.11.0/29 44.0.0.1 120 243 ADr 44.131.14.128/26 44.0.0.1 120 244 ADr 44.131.14.252/31 44.131.14.253 120 245 ADr 44.131.35.128/29 44.0.0.1 120 632 ADC 24.115.112.0/22 24.115.112.147 SECV Cable 100m 0 633 A S 44.0.0.1/32 ucsd-gw 1 882 A S ;;; Added on 2017/05/06 05:36:00 44.131.14.128/26 44.56.53.1 ampr-81.141.195... 50 883 A S ;;; Added on 2017/05/06 02:36:00 44.131.14.252/31 44.56.53.1 ampr-44.131.14.253 50 884 A S ;;; Added on 2017/05/06 02:36:00 44.131.14.253/32 44.56.53.1 SECV Cable 100m 50
leon
On 5/8/2017 9:05 AM, Brian Kantor wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Mon, May 08, 2017 at 07:11:36AM -0400, Leon Zetekoff wrote:
here is snippet of my routing table
242 ADr 44.131.11.0/29 44.0.0.1 120 243 ADr 44.131.14.128/26 44.0.0.1 120 244 ADr 44.131.14.252/31 44.131.14.253 120 245 ADr 44.131.35.128/29 44.0.0.1 120 246 ADr 44.131.56.0/29 44.0.0.1 120
If your path to 44.0.0.1 is via a tunnel, could it be that your packet is showing up at amprgw with both source and destination on tunneled subnets? If so, it will be discarded.
- Brian
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Leon, I don't know if this is the cause of your problem, but it's the case that your gateway is sending encap-to-encap packets to amprgw, where they are being dropped:
gateway inner src #errs indx error type ---------------- ---------------- ----- ---- ------------------------------- 24.115.112.147 44.56.53.1 470 [17] dropped: broadcast inner destination address 24.115.112.147 44.56.53.3 29 [ 8] dropped: encap to encap
The broadcast inner destination address packets are also of some concern. That shouldn't be happening either. - Brian
On Mon, May 08, 2017 at 09:33:45AM -0400, Leon Zetekoff wrote:
It seems any of the BGP sites I can not get to (?)
Others I can get to.
here's part of my routing table:
[admin@core100.wa4zlw.homedns.org] > ip route print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 A S ;;; Default UCSD reply route 0.0.0.0/0 ucsd-gw 250 1 ADC 44.0.0.0/8 44.56.53.1 ucsd-gw 0 226 ADr 44.129.31.0/24 44.0.0.1 120 227 ADr 44.129.128.0/24 44.0.0.1 120 228 ADr 44.130.0.0/16 44.0.0.1 120 229 ADr 44.130.119.0/24 44.130.121.2 120 230 ADr 44.130.121.0/24 44.130.121.2 120 231 ADr 44.130.122.0/23 44.130.122.2 120 232 ADr 44.130.124.0/22 44.130.124.2 120 233 ADr 44.130.224.0/28 44.0.0.1 120 242 ADr 44.131.11.0/29 44.0.0.1 120 243 ADr 44.131.14.128/26 44.0.0.1 120 244 ADr 44.131.14.252/31 44.131.14.253 120 245 ADr 44.131.35.128/29 44.0.0.1 120 632 ADC 24.115.112.0/22 24.115.112.147 SECV Cable 100m 0 633 A S 44.0.0.1/32 ucsd-gw 1 882 A S ;;; Added on 2017/05/06 05:36:00 44.131.14.128/26 44.56.53.1 ampr-81.141.195... 50 883 A S ;;; Added on 2017/05/06 02:36:00 44.131.14.252/31 44.56.53.1 ampr-44.131.14.253 50 884 A S ;;; Added on 2017/05/06 02:36:00 44.131.14.253/32 44.56.53.1 SECV Cable 100m 50
leon
hi brian....beats me...I'll have to check with marius since I'm using his script. I can get to other sites
C:>tracert n1uro.ampr.org
Tracing route to n1uro.ampr.org [44.88.0.9] over a maximum of 30 hops:
1 <1 ms * * xtm520.wa4zlw.homedns.org [10.161.51.3] 2 1 ms <1 ms 2 ms core100.wa4zlw.ampr.org [44.56.53.1] 3 39 ms 36 ms 34 ms gw.ct.ampr.org [44.88.0.1] 4 66 ms 39 ms 38 ms n1uro.ampr.org [44.88.0.9]
Trace complete.
C:>tracert yo2tm.ampr.org
Tracing route to yo2tm.ampr.org [44.182.21.1] over a maximum of 30 hops:
1 <1 ms * * xtm520.wa4zlw.homedns.org [10.161.51.3] 2 1 ms <1 ms <1 ms core100.wa4zlw.ampr.org [44.56.53.1] 3 138 ms 138 ms 137 ms router.yo2loj.ampr.org [44.182.21.254] 4 134 ms 135 ms 135 ms yo2tm.ampr.org [44.182.21.1]
Trace complete.
C:>
Thanks leon
On 5/8/2017 10:27 AM, Brian Kantor wrote:
Leon, I don't know if this is the cause of your problem, but it's the case that your gateway is sending encap-to-encap packets to amprgw, where they are being dropped:
gateway inner src #errs indx error type
24.115.112.147 44.56.53.1 470 [17] dropped: broadcast inner destination address 24.115.112.147 44.56.53.3 29 [ 8] dropped: encap to encap
The broadcast inner destination address packets are also of some concern. That shouldn't be happening either.
- Brian
On Mon, May 08, 2017 at 09:33:45AM -0400, Leon Zetekoff wrote:
It seems any of the BGP sites I can not get to (?)
Others I can get to.
here's part of my routing table:
[admin@core100.wa4zlw.homedns.org] > ip route print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 A S ;;; Default UCSD reply route 0.0.0.0/0 ucsd-gw 250 1 ADC 44.0.0.0/8 44.56.53.1 ucsd-gw 0 226 ADr 44.129.31.0/24 44.0.0.1 120 227 ADr 44.129.128.0/24 44.0.0.1 120 228 ADr 44.130.0.0/16 44.0.0.1 120 229 ADr 44.130.119.0/24 44.130.121.2 120 230 ADr 44.130.121.0/24 44.130.121.2 120 231 ADr 44.130.122.0/23 44.130.122.2 120 232 ADr 44.130.124.0/22 44.130.124.2 120 233 ADr 44.130.224.0/28 44.0.0.1 120 242 ADr 44.131.11.0/29 44.0.0.1 120 243 ADr 44.131.14.128/26 44.0.0.1 120 244 ADr 44.131.14.252/31 44.131.14.253 120 245 ADr 44.131.35.128/29 44.0.0.1 120 632 ADC 24.115.112.0/22 24.115.112.147 SECV Cable 100m 0 633 A S 44.0.0.1/32 ucsd-gw 1 882 A S ;;; Added on 2017/05/06 05:36:00 44.131.14.128/26 44.56.53.1 ampr-81.141.195... 50 883 A S ;;; Added on 2017/05/06 02:36:00 44.131.14.252/31 44.56.53.1 ampr-44.131.14.253 50 884 A S ;;; Added on 2017/05/06 02:36:00 44.131.14.253/32 44.56.53.1 SECV Cable 100m 50
leon
If you are not using ampr-ripd or rip44d then this could be the issue. What route is used for traffic from the gateway IP to 44.131.14.253? Is this also trying to follow the /31 over the tunnel interface?
The recent update added a "hack" to the RIP daemons so that when adding 44.131.14.252/31 it would also add a route for 44.131.14.253/32 via your normal internet path. If you are not using source-based routing then you probably need something like this to reach me properly.
Thanks, Mike, M6XCV
On 8 May 2017 at 15:55, Leon Zetekoff wa4zlw@backwoodswireless.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ hi brian....beats me...I'll have to check with marius since I'm using his script. I can get to other sites
Yeah, that is exactly what I discovered earlier this afternoon and why your ipip route didn't leave my gateway and went to /dev/null I use the latest ampr-ripd as I believe and that hack is not in it.
Bob VE3TOK
On 2017-05-08 01:40 PM, M6XCV (Mike) wrote:
(Please trim inclusions from previous messages) _______________________________________________ If you are not using ampr-ripd or rip44d then this could be the issue. What route is used for traffic from the gateway IP to 44.131.14.253? Is this also trying to follow the /31 over the tunnel interface?
The recent update added a "hack" to the RIP daemons so that when adding 44.131.14.252/31 it would also add a route for 44.131.14.253/32 via your normal internet path. If you are not using source-based routing then you probably need something like this to reach me properly.
Thanks, Mike, M6XCV
On 8 May 2017 at 15:55, Leon Zetekoff wa4zlw@backwoodswireless.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ hi brian....beats me...I'll have to check with marius since I'm using his script. I can get to other sites
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Mike,
Trace Output:
traceroute to 44.131.14.140 (44.131.14.140), 30 hops max, 60 byte packets 1 kb3vwg-001.ampr.org (44.60.44.1) 0.943 ms 1.068 ms 1.135 ms 2 * * * 3 44.131.14.140 (44.131.14.140) 94.318 ms 95.325 ms 96.556 ms
done ...
At 08:00 America\New_York time, from 44.60.44.10.
- KB3VWG
what software interprate (display) the captured file ? the file extension ask me for program to open it
________________________________
https://u4477715.ct.sendgrid.net/wf/click?upn=Ki4chJONuNfM0VomxEE-2BoZH6yGOE...
It should auto-detect the client IP and captures all packets to/from that address. If the client IP is within 44/8 then it will check the routing table for a gateway and if so include that IP as well. I am not sure if there would be concerns with allowing the user to type an IP address to capture to/from, given that it's a non-production gateway.
On 8 May 2017 at 21:24, R P ronenp@hotmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ what software interprate (display) the captured file ? the file extension ask me for program to open it
I think it's technically writing pcapng, but I used a pcap extension as that seems to be standard practice.
It should work with most packet processing tools, Wireshark is what I use to open captures on my desktop.
Thanks, Mike, M6XCV
I'm changing the format of the files to pcap; disregard the .bin files. After that works, you'll be able to use wireshark or tcpdump. - Brian
On Mon, May 08, 2017 at 08:24:25PM +0000, R P wrote:
what software interprate (display) the captured file ? the file extension ask me for program to open it
Oops. Disregard the disregard, I was confused. - Brian
On Mon, May 08, 2017 at 02:13:33PM -0700, Brian Kantor wrote:
I'm changing the format of the files to pcap; disregard the .bin files. After that works, you'll be able to use wireshark or tcpdump.
- Brian
On Mon, May 08, 2017 at 08:24:25PM +0000, R P wrote:
what software interprate (display) the captured file ? the file extension ask me for program to open it
-
Boudewijn (Bob) Tenty -
Brian Kantor -
Leon Zetekoff -
lleachii＠aol.com -
M6XCV (Mike) -
R P