Marius,
172.31.255.254 is merely my tunl0 IP address, it's a Private IP in the Class B range, using a /32 (a single host on the network), nothing works using that IP address but ping from my 44LAN.
44.60.44.1 is the IP of my eth1 interface, everything is handled on my device via IP forwarding.
I have my tunnel isolated from my 44LAN and Local/WAN network for testing and troubleshooting purposes. This ensures that I'm in fact routing if a packet moves from one network to another. My eth0 is my public facing LAN - which has a 192.168 IP scheme, IP-in-IP is passed to that network from my Public IP address by my Router. eth1 is my 44LAN with the IP address of 44.60.44.1/24.
my setup script can be seen at http://44.60.44.13/startampr
73,
Lynwood KB3VWG
This problem for your IP ( 44.60.44.13 ) is again - link http://44.60.44.13/startampr if ip is from tuneled 44 network is not open.
If pinging or open from not tunelled (not 44) network is all ok ping and open your ip, if pinging from tuneled network is not response or ping .
Testing from Germany, Bulgarian and Romania ampr (44) network - from all those places the result is the same.
Yesterday, about 30 minutes after my first post things were fine and everything was normal, but now again the problem is the same. Analogous problem with n1uro.ampr.org [44.88.0.9] .
73, Miro LZ4NY
----- Цитат от lleachii@aol.com, на 02.08.2013 в 22:25 ----- (Please trim inclusions from previous messages) _______________________________________________ Marius,
172.31.255.254 is merely my tunl0 IP address, it's a Private IP in the Class B range, using a /32 (a single host on the network), nothing works using that IP address but ping from my 44LAN.
44.60.44.1 is the IP of my eth1 interface, everything is handled on my device via IP forwarding.
I have my tunnel isolated from my 44LAN and Local/WAN network for testing and troubleshooting purposes. This ensures that I'm in fact routing if a packet moves from one network to another. My eth0 is my public facing LAN - which has a 192.168 IP scheme, IP-in-IP is passed to that network from my Public IP address by my Router. eth1 is my 44LAN with the IP address of 44.60.44.1/24.
my setup script can be seen at http://44.60.44.13/startampr
73,
Lynwood KB3VWG
Miro,
As of 18:38 GMT the IP of tunl0 is 44.60.44.2/24. I previously used this address, there was no difference in behavior. I've also used 44.60.44.0/8, same results. According to RFC 2003, tunl0's IP is arbitrary as it's IP is not used in encapsulation. The only difference is that the Public can now access my tunnel interface.
Using 172.31.255.254, packets left my border router as IP-in-IP with source 76.114.216.250 and destination of 109.107.73.62 when pinging 44.185.1.1.
The encapsulated packet left my 44gateway as source 44.60.44.10 destination 44.185.1.1.
-Lynwood KB3VWG
Hi Linwood, The problem is not only from my gate, I was interested why is a similar situation, and it's a little awkward when I decide to access any of these addresses can not be used IPIP tunnel and switch to a real address.
I understand that from your address access our, in this situation you have the opportunity to enter the telnet in:
telnet://44.185.92.2 (packet XNET gate Vraca) or telnet://44.182.21.1 (Rumania gate) login with your call and test with: ping YourHamIP - this encapsuled IP network if ping from my network to 44.130.60.100 or 44.130.254.254 all is ok.
I was interested in why this problem occurs only on certain networks and can not explain it so I opened the topic and remarked that I noticed about 24 hours ago - for a while everything was normal.
73, Miro LZ4NY
----- Цитат от lleachii@aol.com, на 03.08.2013 в 00:41 ----- (Please trim inclusions from previous messages) _______________________________________________ Miro,
As of 18:38 GMT the IP of tunl0 is 44.60.44.2/24. I previously used this address, there was no difference in behavior. I've also used 44.60.44.0/8, same results. According to RFC 2003, tunl0's IP is arbitrary as it's IP is not used in encapsulation. The only difference is that the Public can now access my tunnel interface.
Using 172.31.255.254, packets left my border router as IP-in-IP with source 76.114.216.250 and destination of 109.107.73.62 when pinging 44.185.1.1.
The encapsulated packet left my 44gateway as source 44.60.44.10 destination 44.185.1.1.
-Lynwood KB3VWG
Some of the addresses you mention are not in the DNS and will therefore not be reachable from the Internet even if they are reachable via AMPR tunnels. - Brian
On Fri, Aug 02, 2013 at 10:02:01PM -0000, lz4ny@mail.bg wrote:
Hi Linwood, The problem is not only from my gate, I was interested why is a similar situation, and it's a little awkward when I decide to access any of these addresses can not be used IPIP tunnel and switch to a real address.
I understand that from your address access our, in this situation you have the opportunity to enter the telnet in:
telnet://44.185.92.2 (packet XNET gate Vraca) or telnet://44.182.21.1 (Rumania gate) login with your call and test with: ping YourHamIP - this encapsuled IP network if ping from my network to 44.130.60.100 or 44.130.254.254 all is ok.
I was interested in why this problem occurs only on certain networks and can not explain it so I opened the topic and remarked that I noticed about 24 hours ago - for a while everything was normal.
73, Miro LZ4NY
Hello Brian, Yes, I understand it but it was interesting that these addresses are accessed from the Internet but not accessible by AMPR, expecting that once they are available from the internet should be available through the AMPR.
73, Miro LZ4NY
----- Цитат от Brian Kantor (Brian@ucsd.edu), на 03.08.2013 в 01:25 ----- (Please trim inclusions from previous messages) _______________________________________________ Some of the addresses you mention are not in the DNS and will therefore not be reachable from the Internet even if they are reachable via AMPR tunnels. - Brian
On Fri, Aug 02, 2013 at 10:02:01PM -0000, lz4ny@mail.bg wrote: Hi Linwood, The problem is not only from my gate, I was interested why is a similar situation, and it's a little awkward when I decide to access any of these addresses can not be used IPIP tunnel and switch to a real address.
I understand that from your address access our, in this situation you have the opportunity to enter the telnet in:
telnet://44.185.92.2 (packet XNET gate Vraca) or telnet://44.182.21.1 (Rumania gate) login with your call and test with: ping YourHamIP - this encapsuled IP network if ping from my network to 44.130.60.100 or 44.130.254.254 all is ok.
I was interested in why this problem occurs only on certain networks and can not explain it so I opened the topic and remarked that I noticed about 24 hours ago - for a while everything was normal.
73, Miro LZ4NY _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
-------------------------------------
Завладей лятото със СуперХостинг.БГ! Само сега 50 GB пространство и неограничен трафик за 6,25 лв. на месец! http://www.superhosting.bg/SummerPromo2013/?utm_source=Mail.BG&utm_mediu...
The issue is that there are gates (misconfigured IMHO) which respond properly when accessed from the internet (via the gateway) and are NOT reachable via tunnel.
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Brian Kantor Sent: Saturday, August 03, 2013 01:25 To: AMPRNet working group Subject: Re: [44net] ipip tunnel
(Please trim inclusions from previous messages) _______________________________________________ Some of the addresses you mention are not in the DNS and will therefore not be reachable from the Internet even if they are reachable via AMPR tunnels. - Brian
Marius,
My tunl0 IP address is currently 44.60.44.2/24; please test and update us.
You noted that you cannot reach http://44.60.44.13/startampr Is that from the public Internet as well? It may help if you could review the script, so we'll be discussing the same configuration.
Also, I've confirmed that my tunnel is encapsulating with the correct source (192.168.x.x - which is NATed to my public IP) and destination IP addresses (the destination 44Gateway in my route table). My gateway DOESN'T use the tunl0 IP address unless I enter 'ping -i tunl0' on the console.
Thanks to all who troubleshoot, we've been trying to understand why we have issues between some gateways for quite some time.
-Lynwood KB3VWG
On 08/02/2013 06:37 PM, marius@yo2loj.ro wrote:
------------------------------------------------------------------------
No matter the architecture (which I can not see because it doesn't work) there shall either be a tunnel endpoint with a 44 source address or a regular private route. Not a tunnel end point with a private source address.
Marius.
Hi Lynwood,
The source address of the packages to be encapsulated has to be your ampr address. Only the IPIP outer envelope is NAT-ed. NAT doesn't care about the data content of the IP frame which in this case is another IP frame. So a correct ipip frame is something like this:
[Ip header from external interface/local interface to be nat-ed to gateway proto 4][ip header from local ampr address to remote ampr address proto 1, 6 or 17][tcp/udp/icmp header] ...payload... [checksums]
This is what you should see on your external interface (nate-ed or not).
Marius.
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of lleachii@aol.com Sent: Saturday, August 03, 2013 15:54 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] ipip tunnel
(Please trim inclusions from previous messages) _______________________________________________ Marius,
My tunl0 IP address is currently 44.60.44.2/24; please test and update us.
You noted that you cannot reach http://44.60.44.13/startampr Is that from the public Internet as well? It may help if you could review the script, so we'll be discussing the same configuration.
Also, I've confirmed that my tunnel is encapsulating with the correct source (192.168.x.x - which is NATed to my public IP) and destination IP addresses (the destination 44Gateway in my route table). My gateway DOESN'T use the tunl0 IP address unless I enter 'ping -i tunl0' on the console.
Thanks to all who troubleshoot, we've been trying to understand why we have issues between some gateways for quite some time.
-Lynwood KB3VWG
On 08/02/2013 06:37 PM, marius@yo2loj.ro wrote:
------------------------------------------------------------------------
No matter the architecture (which I can not see because it doesn't work) there shall either be a tunnel endpoint with a 44 source address or a regular private route. Not a tunnel end point with a private source address.
Marius.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
You may re-use your gateway's internal AMPRnet address on the tunl0 interface but using a /32 netmask.
Let assume you have 3 interfaces eth0 (towards internet), eth1 (local AMPRnet LAN), tunl0 (IPIP full mesh). Your local AMPRnet LAN uses the network 44.a.b.0/24 and eth1 has been assigned 44.a.b.1/24. You may then assign 44.a.b.1/32 to tunl0.
That way packets originating on your local gateway routed via then tunl0 will have the origin 44.a.b.1/32 and other AMPRnet stations will be able to reply to 44.a.b.1 .
The network 44.a.b.0/24 is routed to your gateway anyway, which cover 44.a.b.1/32.
As long as you don't bridge eth1 and tunl0 everything will be fine.
One of my startampr has these first lines:
######################################## ### ENABLE IPIP TUNNEL INTERFACE tunl0 ### ### you must enable the tunnel before specifying routes using the tunnel modprobe ipip ip addr add 44.161.229.1/32 dev tunl0 ### gives tunnel its own TTL of 64 enabling traceroute over tunnel ip tunnel change ttl 64 mode ipip tunl0 ip link set dev tunl0 up
My eth1 also uses that IP address:
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff inet 44.161.229.1/25 brd 44.161.229.127 scope global eth1
73 de Marc, LX1DUC
On 03/08/2013 15:17, Marius Petrescu wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hi Lynwood,
The source address of the packages to be encapsulated has to be your ampr address. Only the IPIP outer envelope is NAT-ed. NAT doesn't care about the data content of the IP frame which in this case is another IP frame. So a correct ipip frame is something like this:
[Ip header from external interface/local interface to be nat-ed to gateway proto 4][ip header from local ampr address to remote ampr address proto 1, 6 or 17][tcp/udp/icmp header] ...payload... [checksums]
This is what you should see on your external interface (nate-ed or not).
Marius.
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of lleachii@aol.com Sent: Saturday, August 03, 2013 15:54 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] ipip tunnel
(Please trim inclusions from previous messages) _______________________________________________ Marius,
My tunl0 IP address is currently 44.60.44.2/24; please test and update us.
You noted that you cannot reach http://44.60.44.13/startampr Is that from the public Internet as well? It may help if you could review the script, so we'll be discussing the same configuration.
Also, I've confirmed that my tunnel is encapsulating with the correct source (192.168.x.x - which is NATed to my public IP) and destination IP addresses (the destination 44Gateway in my route table). My gateway DOESN'T use the tunl0 IP address unless I enter 'ping -i tunl0' on the console.
Thanks to all who troubleshoot, we've been trying to understand why we have issues between some gateways for quite some time.
-Lynwood KB3VWG
On 08/02/2013 06:37 PM, marius@yo2loj.ro wrote:
No matter the architecture (which I can not see because it doesn't
work) there shall either be a tunnel endpoint with a 44 source address or a regular private route. Not a tunnel end point with a private source address.
Marius.
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://hamradio.ucsd.edu/mailman/private/44net/attachments/20130803/47f501e
6/attachment.html>
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
Hello Lynwood,
Please find below results of my tests.
1. From my gateway IP 44.165.2.2 - I do not see your http://44.60.44.13/startampr script - no response to pings
2. From my Windows 8 PC, via AMPRnet VPN IP 44.139.11.10 (IP belongs to Hessu, OH7LZB IP's range) - same as above
3. From my Windows 8 PC, public IP 87.251.250 110 - I CAN SEE http://44.60.44.13/startampr script !!! - no response to pings
Best regards. Tom - sp2lob
Marius,
To clarify:
The OUTTER packet SRC 76.114.216.250 DST <destination gateway>
the INNER packet SRC 44.60.44.x (device being sent from) DST <44.x.x.x>
-Lynwood KB3VWG
Is this update for the Perl or C based software?
We may want to consider a different name for each type; since they had the same name, version numbers, etc, it is somewhat confusing.
-Lynwood KB3VWG
On Tue, Aug 13, 2013 at 5:49 PM, lleachii@aol.com wrote:
Is this update for the Perl or C based software?
We may want to consider a different name for each type; since they had the same name, version numbers, etc, it is somewhat confusing.
They have different names, actually:
rip44d is my Perl implementation.
ampr-ripd is the C implementation, pretty much like rip44d in other respects, both use Linux kernel IPIP tunneling and just manage the routing table.
amprd is an encapsulation daemon with RIP, a bit like the old ipip daemon (IPIP encapsulation in user space) but with RIP built in.
- Hessu
I'm confused about the nuances as well. And, I must say, the distinctions made below may be clear to some, but not to me. I know Hessu was trying to be brief, but in the brevity, I see no difference.
It would be VERY helpful if someone would compare and contrast the options. Why would I use A vs. B vs. C? Are there any advantages of this one vs. that one? ... etc. I'm not looking to start a "mine is better than yours war". But as a non-programmer, non-linux-expert, who hasn't ever written any Perl, and hasn't written any C in 30+ years, I surely have no idea which one to use and why/when. So I (and probably others) could use help in understanding more completely when/why A vs. B vs. C.
Thanks much,
Michael N6MEF
-----Original Message----- From: 44net-bounces+n6mef=mefox.org@hamradio.ucsd.edu [mailto:44net-bounces+n6mef=mefox.org@hamradio.ucsd.edu] On Behalf Of Heikki Hannikainen Sent: Tuesday, August 13, 2013 9:32 AM To: AMPRNet working group Subject: Re: [44net] rip44d update
(Please trim inclusions from previous messages) _______________________________________________ On Tue, Aug 13, 2013 at 5:49 PM, lleachii@aol.com wrote:
Is this update for the Perl or C based software?
We may want to consider a different name for each type; since they had the same name, version numbers, etc, it is somewhat confusing.
They have different names, actually:
rip44d is my Perl implementation.
ampr-ripd is the C implementation, pretty much like rip44d in other respects, both use Linux kernel IPIP tunneling and just manage the routing table.
amprd is an encapsulation daemon with RIP, a bit like the old ipip daemon (IPIP encapsulation in user space) but with RIP built in.
- Hessu
All,
I think the reason that nodes on the 44 Network cannot reach me is that my router is not allowing connections from the Internet to pass through.
My setup:
Router 1 WAN 76.114.216.250 <> LAN 192.168.x.x <>
Router 2 WAN 192.168.x.2 <> LAN 192.168.y.x
AMPRGW 192.168.y.5
In trying to setup IPTABLES commands to allow IPIP traffic, I've had no success thus far.
On Router1: iptables -t filter -I INPUT -p ipip -j ACCEPT iptables -t filter -I FORWARD -p ipip -j ACCEPT iptables -t nat -I PREROUTING -i vlan1 -p ipip -j DNAT --to-destination 192.168.x.2
On Router2:
iptables -t filter -I INPUT -p ipip -j ACCEPT iptables -t filter -I FORWARD -p ipip -j ACCEPT iptables -t nat -I PREROUTING 1 -s 169.228.66.251 -p ipip -i vlan1 -j DNAT --to-destination 192.168.y.5 iptables -t nat -I PREROUTING 2 -p ipip -i vlan1 -j DNAT --to-destination 192.168.y.5
Any ideas?
-Lynwood KB3VWG
Hello Lynwood,
Put your machine into DMZ zone, just to give it a try...
Best regards. Tom - sp2lob
All,
FYI
While working on my firewall issue (which is almost solved - I'm managing to pass ipencap traffic through my border device); I was searching for an IP that is sending me encap traffic. Looking at Google.com search results, I found the encap file publicly available via the URL:
https://portal.ampr.org/getdata.php?t=encap
-Lynwood KB3VWG
All,
Please verify my gateway is reachable over AMPR. It appears the problem was not having an iptables rule allowing IPENCAP.
ping and traceroute ping GW- 44.60.44.1 DNS at 44.60.44.3 HTTP at 44.60.44.10, 11, 12 and 13 Public Echolink Proxy 44.60.44.253:443 and 44.60.44.254:80
-Lynwood KB3VWG
On 08/03/2013 09:28 PM, lleachii@aol.com wrote:
Marius,
To clarify:
The OUTTER packet SRC 76.114.216.250 DST <destination gateway>
the INNER packet SRC 44.60.44.x (device being sent from) DST <44.x.x.x>
-Lynwood KB3VWG
Visible at 44.24.10.1 and 44.24.10.2
------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays
On Mon, Aug 19, 2013 at 1:24 PM, lleachii@aol.com wrote:
(Please trim inclusions from previous messages) ______________________________**_________________ All,
Please verify my gateway is reachable over AMPR. It appears the problem was not having an iptables rule allowing IPENCAP.
ping and traceroute ping GW- 44.60.44.1 DNS at 44.60.44.3 HTTP at 44.60.44.10, 11, 12 and 13 Public Echolink Proxy 44.60.44.253:443 and 44.60.44.254:80
-Lynwood KB3VWG
On 08/03/2013 09:28 PM, lleachii@aol.com wrote:
Marius,
To clarify:
The OUTTER packet SRC 76.114.216.250 DST <destination gateway>
the INNER packet SRC 44.60.44.x (device being sent from) DST <44.x.x.x>
-Lynwood KB3VWG
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Your gateway replies with a private IP:
3 172.31.255.254 (172.31.255.254) 203.731 ms 233.349 ms 233.076 ms
You should initialize your tunnel interface (tunl0, ampr0, etc) with an address from 44/8.
You may reuse an IP from your internal LAN, for example if you gateway has 44.60.44.1/24 on the inside, you may assign 44.60.44.1/32 to your tunnel interface.
This will solve multiple issues:
1) your gateway will use 44.60.44.1 as source IP for any connections that will be initiated from the gateway host via the tunnel interface. So other AMPR stations will actually be able to reply to your gatway's packets.
2) Should your gateway ever have to reply with some ICMP message, the source IP will correctly identify where the ICMP message was generated.
73 de Marc, LX1DUC
On 19/08/2013 22:24, lleachii@aol.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ All,
Please verify my gateway is reachable over AMPR. It appears the problem was not having an iptables rule allowing IPENCAP.
ping and traceroute ping GW- 44.60.44.1 DNS at 44.60.44.3 HTTP at 44.60.44.10, 11, 12 and 13 Public Echolink Proxy 44.60.44.253:443 and 44.60.44.254:80
-Lynwood KB3VWG
On 08/03/2013 09:28 PM, lleachii@aol.com wrote:
Marius,
To clarify:
The OUTTER packet SRC 76.114.216.250 DST <destination gateway>
the INNER packet SRC 44.60.44.x (device being sent from) DST <44.x.x.x>
-Lynwood KB3VWG
-------------- next part -------------- An HTML attachment was scrubbed... URL: http://hamradio.ucsd.edu/mailman/private/44net/attachments/20130819/43bd9d7a/attachment.html
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
Marc,
I have changed tunl0 to 44.60.44.1/32
Thanks,
-Lynwood KB3VWG
On 08/19/2013 04:44 PM, lx1duc@rlx.lu wrote:
Your gateway replies with a private IP:
3 172.31.255.254 (172.31.255.254) 203.731 ms 233.349 ms 233.076 ms
You should initialize your tunnel interface (tunl0, ampr0, etc) with an address from 44/8.
You may reuse an IP from your internal LAN, for example if you gateway has 44.60.44.1/24 on the inside, you may assign 44.60.44.1/32 to your tunnel interface.
This will solve multiple issues:
- your gateway will use 44.60.44.1 as source IP for any connections
that will be initiated from the gateway host via the tunnel interface. So other AMPR stations will actually be able to reply to your gatway's packets.
- Should your gateway ever have to reply with some ICMP message, the
source IP will correctly identify where the ICMP message was generated.
73 de Marc, LX1DUC On 08/03/2013 09:28 PM, lleachii@aol.com wrote:
Marius,
To clarify:
The OUTTER packet SRC 76.114.216.250 DST <destination gateway>
the INNER packet SRC 44.60.44.x (device being sent from) DST <44.x.x.x>
-Lynwood KB3VWG
All,
I'm not sure it's safe to suggest that someone having issues with their gateway behind a firewall simply add it to the DMZ, especially in DD-WRT.
I have been working with DD-WRT, the following should work under Administration > Commands > (Save Firewall):
Command if Static IP:
iptables -t nat -I PREROUTING -p ipencap -d <GW Public IP> -j DNAT --to-destination <GW LAN IP> iptables -I FORWARD -p ipencap -d <GW LAN IP> -j ACCEPT
If dynamic IP - using the interface (WAN is vlan1 in DD-WRT in OpenWRT it is eth0.1):
iptables -t nat -I PREROUTING -p ipencap -i vlan1 -j DNAT --to-destination <GW LAN IP> iptables -I FORWARD -p ipencap -d <GW LAN IP> -j ACCEPT
If you have a firewall on your 44 Gateway, be sure to allow IPENCAP into the device:
iptables -t filter -I INPUT -p ipencap -d <GW LAN IP> -j ACCEPT
73,
Lynwood KB3VWG
No matter the architecture (which I can not see because it doesn't work) there shall either be a tunnel endpoint with a 44 source address or a regular private route. Not a tunnel end point with a private source address.
Marius.
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of lleachii@aol.com Sent: Friday, August 02, 2013 22:25 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] ipip tunnel
(Please trim inclusions from previous messages) _______________________________________________ Marius,
172.31.255.254 is merely my tunl0 IP address, it's a Private IP in the Class B range, using a /32 (a single host on the network), nothing works using that IP address but ping from my 44LAN.
44.60.44.1 is the IP of my eth1 interface, everything is handled on my device via IP forwarding.
I have my tunnel isolated from my 44LAN and Local/WAN network for testing and troubleshooting purposes. This ensures that I'm in fact routing if a packet moves from one network to another. My eth0 is my public facing LAN - which has a 192.168 IP scheme, IP-in-IP is passed to that network from my Public IP address by my Router. eth1 is my 44LAN with the IP address of 44.60.44.1/24.
my setup script can be seen at http://44.60.44.13/startampr
73,
Lynwood KB3VWG
On Fri, Aug 2, 2013 at 10:25 PM, lleachii@aol.com wrote:
172.31.255.254 is merely my tunl0 IP address, it's a Private IP in the Class B range, using a /32 (a single host on the network), nothing works using that IP address but ping from my 44LAN.
44.60.44.1 is the IP of my eth1 interface, everything is handled on my device via IP forwarding.
Lynwood,
When someone does a traceroute to your network behind the gateway, and you receive traceroute's packets on the tunl0 interface, I think your kernel will respond to those packets using the tunl0 IP address. If you have a private 172.31 address there, instead of a 44 address, the 172.31 address will show up on the traceroute instead of your registered net-44 address (unless the non-amprnet source address will be filtered at the other end of the tunnel). Also, when any applications on that router box (if you have any) will initiate connections to the amprnet, they'll use the outgoing interface's IP address as the source address by default, unless some other magic configuration is applied.
It might be a good idea to just reuse the 44.60.44.1 address on tunl0, with a /32 mask. Might reduce confusion at some point later on. You're right in that it doesn't really make any difference when simply forwarding packets.
- Hessu
-
Brian Kantor -
Heikki Hannikainen -
K7VE - John -
lleachii＠aol.com -
lz4ny＠mail.bg -
Marc, LX1DUC -
Marius Petrescu -
Michael E. Fox - N6MEF -
sp2lob＠tlen.pl