19 May
2014
19 May
'14
4:48 p.m.
On 2014-05-19 23:26, Pedro Converso wrote:
(Please trim inclusions from previous messages)
_______________________________________________
Hello fellows 44 crew
I have a ping not returning syndrome from my 44 address via Internet.
From any ampr system ping to 44.153.0.1 are answered ok, but
from internet don't receive answer to pings sent to 44.153.0.1
To try thru Internet I use https://www.wormly.com/test_remote_ping
setting 44.153.0.1 as destination for pings.
System is an ubuntu 10.03 and jnos2.0i, locally pings returns ok.
I made some traces that follows, some related autoexec.nos are at end.
Your traces are tcpdumps; you might want to try traceroute (or tracepath
when on Linux) instead.
[..]
Mon May 19 16:36:37 2014 - tun0 recv:
IP: len 104 169.228.66.251->44.153.0.1 ihl 20 ttl 39 prot IP
IP: len 84 184.72.226.23->44.153.0.1 ihl 20 ttl 38 DF prot ICMP
ICMP: type Echo Request id 58952 seq 1
That is a IPv4-in-IPv4-ICMPv4 packet.
Mon May 19 16:36:37 2014 - tun0 sent:
IP: len 84 44.153.0.1->184.72.226.23 ihl 20 ttl 175 prot ICMP
ICMP: type Echo Reply id 58952 seq 1
That is a IPv4-ICMPv4 packet.
That should match the former, IPv4-IPv4-ICMPv4
ifconfig tun0 ipaddress 44.153.0.10
ifconfig tun0 netmask 255.255.255.0
ifconfig tun0 mtu 1500
shell ifconfig tun0 44.153.0.3 pointopoint 44.153.0.10 mtu 1500 up
Please note that you are mixing up typical 'tunX' usage.
Typically 'tunX' is the tun/tap interface. The above makes this a
IPv4-in-IPv4 tunnel.
Interresting that you see the encapsulated result on tun0 though, one
would expect to see that on the underlying interface, not here.
That 1500 MTU is likely bad, unless you run jumboframes towards UCSD.
shell iptables -t nat -A PREROUTING -d 44.153.0.10/32
--proto 4 \-j DNAT
--to 44.153.0.1
This makes all packets going to 44.153.0.10 of type ipencap
(IPv4-in-IPv4) be send to 44.153.0.1 instead of the real destination.
Is that really what you want to do, and why?
shell iptables -t nat -A PREROUTING -d 44.153.0.10/32
--proto 94 \-j DNAT
--to 44.153.0.1
Same but for the 94 variant of IPv4-in-IPv4. (though in theory one is
allowed to use any IP version inside of the other there)
Same Q: why do you do that?
shell iptables -t nat -A POSTROUTING -s 44.153.0.1/32
-o eth0 -p 4
shell iptables -t nat -A POSTROUTING -s 44.153.0.1/32 -o eth0 -p 94
Except for counting packets, these two rules have no effect.
shell sudo -s iptables -t nat -A PREROUTING -d
44.153.0.3/32 -p tcp --dport
23 \-j DNAT --to 44.153.0.1:23
This causes everything towards .3 to go to .1
shell sudo -s iptables -t nat -A PREROUTING -d
44.153.0.3/32 -p tcp --dport
6300 \-j DNAT --to 44.153.0.1:23
Same but redirecting port 6300.
shell sudo -s iptables -t nat -A PREROUTING -d
lu7abf.org.ar -p tcp --dport
6300 \-j DNAT --to 44.153.0.1:23
shell sudo -s iptables -t nat -A POSTROUTING -s
44.153.0.1/32 -o eth0 -j
MASQUERADE
shell sudo -s iptables -t nat -A POSTROUTING -s 44.153.0.10/32 -o eth0 -j
MASQUERADE
This causes these two 44 net addresses to become NATted when they try
and communicate to your local network.
As those addresses are local though, it is unlikely there are used to
ever communicate with services living on eth0, unless you force programs
to do so.
ifconfig encap ip 44.153.0.1
ifconfig encap mtu 1500
ifconfig encap netmask 0xffffffff
ifconfig encap broadcast 255.255.255.255
ifc encap descript "IPIP Encapulation interface"
And here you configure a secondary encapsulation interface. Are you sure
you need two?
Greets,
Jeroen