29 May
2017
29 May
'17
2:49 p.m.
I get the following error in the statistic file of amprgate
5.29.18.144 169.228.66.251 4122 [19] dropped: non-44 inner source address
when i look on the PCAP file here is what I see
#1 0.000000 169.228.66.251 -> 192.168.1.180 IPv4 20
#2 9.996091 169.228.66.251 -> 192.168.1.180 IPv4 20
#3 19.997040 169.228.66.251 -> 192.168.1.180 IPv4 20
#4 29.996386 169.228.66.251 -> 192.168.1.180 IPv4 20
#5 39.995885 169.228.66.251 -> 192.168.1.180 IPv4 20
#6 49.997226 169.228.66.251 -> 192.168.1.180 IPv4 20
#7 59.996845 169.228.66.251 -> 192.168.1.180 IPv4 20
#8 69.996284 169.228.66.251 -> 192.168.1.180 IPv4 20
#9 79.996422 169.228.66.251 -> 192.168.1.180 IPv4 20
#10 90.006277 169.228.66.251 -> 192.168.1.180 IPv4 20
#11 99.996794 169.228.66.251 -> 192.168.1.180 IPv4 20
#12 109.996173 169.228.66.251 -> 192.168.1.180 IPv4 20
#13 120.008209 169.228.66.251 -> 192.168.1.180 IPv4 20
#14 129.997756 169.228.66.251 -> 192.168.1.180 IPv4 20
#15 139.996572 169.228.66.251 -> 192.168.1.180 IPv4 20
inside the PCAP here is what I see
Frame 1: 20 bytes on wire (160 bits), 20 bytes captured (160 bits)
Encapsulation type: Raw IP (7)
Arrival Time: May 29, 2017 08:59:04.652285000 CEST
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1496041144.652285000 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 20 bytes (160 bits)
Capture Length: 20 bytes (160 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: raw:ip]
Raw packet data
Internet Protocol Version 4, Src: 169.228.66.251, Dst: 192.168.1.180
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 20
Identification: 0x0000 (0)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 255
Protocol: IPIP (4)
Header checksum: 0x0caa [validation disabled]
[Good: False]
[Bad: False]
Source: 169.228.66.251
Destination: 192.168.1.180
[Source GeoIP: La Jolla, CA, United States, AS7377 University of California, San Diego,
32.880699, -117.235901]
[Source GeoIP City: La Jolla, CA]
[Source GeoIP Country: United States]
[Source GeoIP AS Number: AS7377 University of California, San Diego]
[Source GeoIP Latitude: 32.880699]
[Source GeoIP Longitude: -117.235901]
[Destination GeoIP: Unknown]
Collapse Tree
I dont understand what is the problem
May anyone help ?
Thank Forward
Ronen - 4Z4ZQ
29 May
29 May
3 p.m.
Ronen, the error message tells you what the problem is pretty clearly.
You are sending packets to the gateway with a source address that isn't yours.
In fact, it's the gateway's address. This means that something in your
router is using 169.228.66.251 as the source address of outgoing encapped
packets, which is an error. It probably should be 44.138.1.1.
The same packets have ANOTHER problem as well: they are addressed to
the destination 192.168.1.180, which is a local-network-only address
and should never leave your network. They should NOT be sent to the
ampr gateway.
Unfortunately, I don't know enough about Mikrotik router setup to help
you find the cause of the problem. Perhaps someone who has a Mikrotik
set up can help you find what is wrong with your configuration.
- Brian
On Mon, May 29, 2017 at 06:49:04PM +0000, R P wrote:
> I get the following error in the statistic file of amprgate
>
> 5.29.18.144 169.228.66.251 4122 [19] dropped: non-44 inner source address
>
> when i look on the PCAP file here is what I see
>
> #1 0.000000 169.228.66.251 -> 192.168.1.180 IPv4 20
> #2 9.996091 169.228.66.251 -> 192.168.1.180 IPv4 20
> #3 19.997040 169.228.66.251 -> 192.168.1.180 IPv4 20
> #4 29.996386 169.228.66.251 -> 192.168.1.180 IPv4 20
> #5 39.995885 169.228.66.251 -> 192.168.1.180 IPv4 20
> #6 49.997226 169.228.66.251 -> 192.168.1.180 IPv4 20
> #7 59.996845 169.228.66.251 -> 192.168.1.180 IPv4 20
> #8 69.996284 169.228.66.251 -> 192.168.1.180 IPv4 20
> #9 79.996422 169.228.66.251 -> 192.168.1.180 IPv4 20
> #10 90.006277 169.228.66.251 -> 192.168.1.180 IPv4 20
> #11 99.996794 169.228.66.251 -> 192.168.1.180 IPv4 20
> #12 109.996173 169.228.66.251 -> 192.168.1.180 IPv4 20
> #13 120.008209 169.228.66.251 -> 192.168.1.180 IPv4 20
> #14 129.997756 169.228.66.251 -> 192.168.1.180 IPv4 20
> #15 139.996572 169.228.66.251 -> 192.168.1.180 IPv4 20
>
> I dont understand what is the problem
> May anyone help ?
>
> Thank Forward
>
> Ronen - 4Z4ZQ
>
>
3:24 p.m.
Dear Brian
thanks for the explain ... I dont have any 169.228.66.251 IP beside the tunnel endpoint
definition and everything works at my side .....
I will try to add a firewall rule to catch any source address of 169.228.66.251 for
outbound traffic to see what the log will tell
May it be any reply of my router to spoofed (faked ) addresses ?
as for the 192.168.1.180 that is a valid address ...
________________________________
3:45 p.m.
Brian
I send all outbound traffic to new AMPRGW do you route the data from the new amprgw
back to the Firewall on the old amprgw ? how come it see something from my system ? all
my packets should arrive to the new GW and not to be logged unless the firewall and
the log is on a system before the two gateways .
A is active route rule
0 A S 0.0.0.0/0 192.168.1.1 1 1 X S 0.0.0.0/0 UCSD 1 2 X S 0.0.0.0/0 192.168.1.1 1 3 A S
0.0.0.0/0 UCSD-NEW 1 4 X S 0.0.0.0/0 192.168.1.1 1 5 X S 8.8.8.8/32 192.168.1.1 1 6 X S
44.24.244.4/32 192.168.1.180 bridge-local 1 7 ADC 44.138.1.0/24 44.138.1.1 bridge-local 0
8 A S 169.228.34.84/32 192.168.1.1 1 9 A S 169.228.66.251/32 192.168.1.1 1 10 ADC
192.168.1.0/24 192.168.1.180 bridge-local 0
very strange ...
________________________________
4:13 p.m.
Ronen,
Are you doing NATing to your 44 addresses or to your GW?
Perhaps somewhere in your mangle or other rules, you accidentally change
your 44 SRC to AMPRGW and DST to and Local LAN IP.
Perhaps there's another network routed through your device that's
leaking packets to the tunnel(s)?
- Lynwood
KB3VWG
8:17 p.m.
Maybe for those not aware of the "private" address ranges that should
not be sent outside their own network, here they are:
127.0.0.0/8 - loopback addresses per RFC1122
10.0.0.0/16 - private single class A network per RFC 1918
172.16.0.0/12 - private 16 class B networks per RFC 1918
192.168.0.0/16 - private 256 class C networks per RFC 1918
169.254.0.0/16 - link-local (zero conf) address space per RFC 3927
44.128.0.0/16 - test address space as defined by the AMPR network
None of these addresses shall ever leave your local network under any
circumstances.
For additional info: https://tools.ietf.org/html/rfc6890
Marius, YO2LOJ
2732
days inactive
2733
days old
6 comments
4 participants
participants (4)
-
Brian Kantor -
lleachii＠aol.com -
Marius Petrescu -
R P