Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 22 replies
  • Subscribers 2 subscribers
  • Views 21967 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
    see my working example image below

    add this to allow users -OUT


    I feel your pain..one week. ouch!

    Mike


    fresh setup http://www.astaro.com/sites/default/files/astaro-Howto-initial-setup.swf
  • 0 in reply to MikeinNYC
    I will try that when I get home.  I am unsure if this will resolve my external interface using a 192.168.2.x address to communicate with public addresses on the internet?  I should at least see syn-ack return from the 76.13.114.90 host and be dropped at the gateway if no rule allowed it back in.  I am not seeing any return syn-ack from 76.13.114.90 because I believe it is using the NAT'd addres 192.168.2.254 as the source.

    Thanks for your help.
  • 0 in reply to spideyman
    The masquerade rule looks good, do you have any DNAT/SNAT/Full NAT rules defined?
  • 0 in reply to Jack Daniel
    I dont believe that I have any DNAT/SNAT/Full NAT defined.  Would I need to create one to allow the public address to be put in place of the private source address?  Everything on the Astaro UTM seems fine, its just not allowing the internal users to have a public IP address when talking to the internet.

    I have searched the forum quite a bit trying to resolve my answer, I usually do not post questions as the tend to be discussed and resolved already with a search.  But for the life of me, I cannot get this to work, and really would like to use this UTM.

    Thanks for all the ideas so far.  Any further input will be greatly appreciated.
  • 0
    Spidey, is this a home-use license?  If so, why don't you try configuring the HTTP/S Proxy in Transparent mode to see if you can browse via that.  I think it handles masquing for itself, so that would let you test to be sure everything else is working.  I haven't ever heard of a problem like this, so I'd be listening to Jack's insights in trying to tack the cause.

    Cheers - Bob
  • 0 in reply to BAlfson
    Yes this is for home use.  I hope everyone will still help me the same [:D] even though it is for my personal use.  I like the web interface and features but anyway.

    I will try all suggestions when I get home in a couple of hours and report back.  I am not sure if I should be happy or sad about this issue, but hope it to be a learning experience for anyone else with this issue (if any exist).
  • 0


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



    Not sure what you mean. The IP address looks like real address. I am surprised at /22 for a network from an ISP, they usually provide homes with a /32.

    Where did you get the /22 address from?

    Ian M
  • 0 in reply to RFCat_vk_01
    I created a SNAT rule that didnt seem to work either.  Anyone have any ideas?  For some reason, the internal address is not getting replaced by the public address assigned by comcast.  Help!

    SNAT.jpg
  • 0
    dhcp or static? When in doubt reboot...everything. Comcast home is crap they intentionally block port 80 use transparancy to 8080 like balfson said, you need static ips for relibility.

    It's a motorola modem my guess. 
    Unplug and plug that modem... sometime simple works. otherwise a hammer might work.
    kidding. We'll get it working.
    Mike
  • 0
    Spidey, this all sounds impossible.  The SNAT shouldn't be used, just a regular Masq rule, 'Internal (Network) -> External', should be all you need.  None of this sounds like "normal" difficulties, so, as early as it is in your Astaro configuration, I think you should zap the hard drive and reinstall from ISO.  In fact, I think you should burn a new CD and do so at a much lower speed.  Not that I think this was the problem, just that this is so strange that I think you really should start over from scratch.

    Cheers - Bob