My understanding is that it's working correctly, because the icmp reply is sent back to 2.238.198.249 inside the tunnel and towards the amprnet router (169.228.66.251).
Unfortunately there's something wrong in the middle because no packets are actually reaching 2.238.198.249
It must be something in your 2.238.198.249 system or the path to it, because I can ping 44.134.160.1 without problem from other internet hosts.
Rob
Marco's gateway system 91.121.90.186, was temporarily blocked at the UCSD ampgw router. I have removed that block and 44.134.160.1 is now reachable from the Internet. - Brian
On Fri, Apr 21, 2017 at 10:13:22PM +0200, Rob Janssen wrote:
(Please trim inclusions from previous messages) _______________________________________________
My understanding is that it's working correctly, because the icmp reply is sent back to 2.238.198.249 inside the tunnel and towards the amprnet router (169.228.66.251).
Unfortunately there's something wrong in the middle because no packets are actually reaching 2.238.198.249
It must be something in your 2.238.198.249 system or the path to it, because I can ping 44.134.160.1 without problem from other internet hosts.
Rob
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Hi Rob and all,
thanks for the prompt answer. It's working now with the help of Brian.
However I'm still sending non-44 source addresses to the amprnet router. An example:
22:27:23.139944 IP 169.228.66.251 > 91.121.90.186: IP 77.236.192.34 > 44.134.19.3: ICMP host 93.89.157.209 unreachable, length 81 (ipip-proto-4) *22:27:23.139999 IP 91.121.90.186 > 169.228.66.251: IP 77.236.192.34 > 44.134.19.3: ICMP host 93.89.157.209 unreachable, length 81 (ipip-proto-4) *
anybody knows how to filter this traffic with IPTables ? It would be very helpful.
Thanks Marco
On 21/04/2017 22:13, Rob Janssen wrote:
(Please trim inclusions from previous messages) _______________________________________________
My understanding is that it's working correctly, because the icmp reply is sent back to 2.238.198.249 inside the tunnel and towards the amprnet router (169.228.66.251).
Unfortunately there's something wrong in the middle because no packets are actually reaching 2.238.198.249
It must be something in your 2.238.198.249 system or the path to it, because I can ping 44.134.160.1 without problem from other internet hosts.
Rob
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Marco,
PE1CHL assisted me with this some time ago, the reasoning is outlined here:
http://wiki.ampr.org/wiki/Setting_up_a_gateway_on_OpenWRT https://en.wikipedia.org/wiki/Virtual_routing_and_forwarding
You need to tell your interfaces and IPs to use specific route tables.
This is done on Linux using the command: ip rule
# OPTIONAL# ip rule add from <your AMPRLAN> to 192.168.0.0/24 table main priority 22 ip rule add to <your AMPRLAN> table main priority 44 ip rule add dev tunl0 table 44 priority 45 ip rule add dev br-amprnet table 44 priority 46 ip rule add from <your AMPRLAN> table 44 priority 47
73,
- Lynwood KB3VWG
Also see the bolded section mentioning PE1CHL at: http://wiki.ampr.org/wiki/Startampr
"*Please note that: any machine acting as an AMPRNet Gateway must explicitly create high-priority routing rules for all traffic addressed to or from eth0..."
- Lynwood *
Hi Lynwood,
your answer was very helpful. My configuration looks like very similar. I will study the differences and will test any improvements eventually.
Thanks so much Marco iw2ohx
On 22/04/2017 01:48, lleachii--- via 44Net wrote:
(Please trim inclusions from previous messages) _______________________________________________ Also see the bolded section mentioning PE1CHL at: http://wiki.ampr.org/wiki/Startampr
"*Please note that: any machine acting as an AMPRNet Gateway must explicitly create high-priority routing rules for all traffic addressed to or from eth0..."
- Lynwood
What I forgot to mention though - is that my firewall rules and instructions on the Wiki do not currently permit this for security and zoning reasons.
My understanding from the route table, that I would reach:
- BGPed IPs - and IPENCAPed subnets on BGPed 44 addresses
over my WAN interface.
I believe the following allow rule would be necessary:
iptables -I FORWARD -s <AMPRLAN> -d 44.0.0.0/8 -o eth0 -j ACCEPT
Those needing to block such access should make a similar rule to DROP. This still won't allow the BGP subnet to reach the 44 directly without a tunnel...but henc using the Public IP and going out the WAN...and we've discussed that in the past.
- Lynwood
PS: someone mentioned they cant reach me on aol.com, use gmail.
Lynwood.
Yeah... aol.com mail server seem to be very sensitive&restrictive.
Best regards. --- Tom - SP2L
Sent from Xperia Z1 with AquaMail http://www.aqua-mail.com
Also, those who for some reason DO NOT USE what's called 'NAT-MASQUERADE' on their outbound WAN by default will have to make an iptbales rule to masquerade the traffic for this to work.
-Lynwood
On 04/23/2017 06:38 AM, lleachii@aol.com wrote:
What I forgot to mention though - is that my firewall rules and instructions on the Wiki do not currently permit this for security and zoning reasons.
My understanding from the route table, that I would reach:
- BGPed IPs
- and IPENCAPed subnets on BGPed 44 addresses
over my WAN interface.
I believe the following allow rule would be necessary:
iptables -I FORWARD -s <AMPRLAN> -d 44.0.0.0/8 -o eth0 -j ACCEPT
Those needing to block such access should make a similar rule to DROP. This still won't allow the BGP subnet to reach the 44 directly without a tunnel...but henc using the Public IP and going out the WAN...and we've discussed that in the past.
- Lynwood
PS: someone mentioned they cant reach me on aol.com, use gmail.
-
Brian Kantor -
lleachii＠aol.com -
Marco Di Martino -
Rob Janssen -
SP2L Tom