Re: [44net] ipip tunnel

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(a)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