Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 22 replies
  • Subscribers 2 subscribers
  • Views 21968 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

No Internet Access (IP Masquerading - Detailed)

spideyman
I am having problems with users behind the firewall being able to access the internet.  I will try and provide as much information as possible since I have been trying to figure this out for a week.

I started with a fresh install of Astaro on an old HP p4 machine with 1GB memory.  I isntalled it and followed the wizard when you first connect to the web management portal.  I have 2 interfaces:

eth0 is inside (192.168.2.0/24)
eth1 is outside (Comcast IP)

I setup the outside interface (eht1) the allow for DHCP from the initial setup wizard.  I have also configured the inside interface to serve DHCP address, which work fine.  I have DNS forwarders set to use comcasts DNS servers.  The following are the hosts attached to the network:

Windows 7 Machine
IPv4 Address. . . . . . . . . . . : 192.168.2.254
IPv4 Address. . . . . . . . . . . : 192.168.2.254
Default Gateway . . . . . . . . . : 192.168.2.100 (Astaro UTM)
DHCP Server . . . . . . . . . . . : 192.168.2.100
DNS Servers . . . . . . . . . . . : 192.168.2.100

Astaro Gateway
Management IP 192.168.2.100
Public IP 67.x.x.95

Now, on the Astaro UTM, I can resolve hostnames:

spideyfw:/root # nslookup www.cnn.com
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
Name:   www.cnn.com
Address: 157.166.224.25
Name:   www.cnn.com
Address: 157.166.224.26
Name:   www.cnn.com
Address: 157.166.226.25
Name:   www.cnn.com
Address: 157.166.226.26
Name:   www.cnn.com
Address: 157.166.255.18
Name:   www.cnn.com
Address: 157.166.255.19

I can ping hostnames:

spideyfw:/root # ping www.yahoo.com
PING any-fp.wa1.b.yahoo.com (69.147.125.65) 56(84) bytes of data.
64 bytes from ir1.fp.vip.re1.yahoo.com (69.147.125.65): icmp_seq=1 ttl=52 time=43.5 ms
64 bytes from ir1.fp.vip.re1.yahoo.com (69.147.125.65): icmp_seq=2 ttl=52 time=42.3 ms
64 bytes from ir1.fp.vip.re1.yahoo.com (69.147.125.65): icmp_seq=3 ttl=52 time=45.2 ms
64 bytes from ir1.fp.vip.re1.yahoo.com (69.147.125.65): icmp_seq=4 ttl=52 time=45.1 ms
64 bytes from ir1.fp.vip.re1.yahoo.com (69.147.125.65): icmp_seq=5 ttl=52 time=42.5 ms

I can ping IP addresses:

spideyfw:/root # ping 69.147.125.65
PING 69.147.125.65 (69.147.125.65) 56(84) bytes of data.
64 bytes from 69.147.125.65: icmp_seq=6 ttl=52 time=47.3 ms
64 bytes from 69.147.125.65: icmp_seq=25 ttl=52 time=2507 ms
64 bytes from 69.147.125.65: icmp_seq=28 ttl=52 time=41.5 ms
64 bytes from 69.147.125.65: icmp_seq=29 ttl=52 time=42.4 ms

So all that seems good, but I am not able to access anything from internal > external (eth0 > eth1).  Below are my settings:

Packet Filter Rules:



NAT Rules:



Dashboard:



Interfaces:



What I think is wrong is IP masquerading is not working.  I ran a TCP dump on both interfaces, and this is what I found:

(inside interface)
spideyfw:/root # tcpdump -nni eth0 host 76.13.114.90
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
21:37:26.473563 IP 192.168.2.254.50669 > 76.13.114.90.80: S 2738589191:2738589191(0) win 8192 
21:37:28.536049 IP 192.168.2.254.50671 > 76.13.114.90.80: S 2712732671:2712732671(0) win 8192 
21:37:31.543599 IP 192.168.2.254.50671 > 76.13.114.90.80: S 2712732671:2712732671(0) win 8192 

3 packets captured
3 packets received by filter
0 packets dropped by kernel

(outside interface)
spideyfw:/root # tcpdump -nni eth1 host 76.13.114.90
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
21:38:24.307310 IP 192.168.2.254.50693 > 76.13.114.90.80: S 3046422443:3046422443(0) win 8192 
21:38:27.298581 IP 192.168.2.254.50693 > 76.13.114.90.80: S 3046422443:3046422443(0) win 8192 
21:38:29.377588 IP 192.168.2.254.50695 > 76.13.114.90.80: S 3120491574:3120491574(0) win 8192 

3 packets captured
3 packets received by filter
0 packets dropped by kernel

The outside interface is using a non-routeable IP address, hence no syn-ack to the syn packets.  IP forwarders is enabled:

spideyfw:/root # cat /proc/sys/net/ipv4/ip_forward
1

I have no clue what to do next.  I really would like to use the astaro gateway, so any help is greatly appreciated.  I hope I didnt provide way too much info, but I wanted to be as thorough as possible.


This thread was automatically locked due to age.
  • 0 in reply to Scott_Klassen
    Registering the MAC would make sense if I received a new cable modem.  I am still confused on how the modem receives the IP address and my linksys router is a 24.x.x.x and with the astaro its a 67.x.x.x.  When I use my old dlink router, I still get the 24.x.x.x.  Mac address of the router behind the cable modem should not matter.  At least, that is my understanding.

    Does not seem that I will get this issue resolved [:(] I guess I will have to try something else out.  Thanks for the help everyone.  Any other suggestions are welcomed.
  • 0 in reply to spideyman
    Comcast offers multiple pools of IPs, the 67. v 24. address assignment is probably not relevant, as the cable modem is likely to repeat the same assignments based on the MAC it was first assigned to.  

    If Comcast does enforce MAC registration, you will need to contact them to register the new MAC address of the Astaro's external interface.  Since you can resolve DNS and ping out, MAC registration is probably not the issue.

    Can you get traffic other than ping and DNS out from the Astaro?  Does the up2date section show that it is updating or that there are updates available?  Can you get a web page from console  or SSH?  Try this:

    telnet google.com 80

    See if you get connected, or if it just hangs trying to connect (Ctrl-c to stop).

    Also, enable remote access to WebAdmin and SSH, then see if you can access either of them from an external network.