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

Trouble with HTTP traffic from VPC

Ok folks. Here's the story.  I forgot the password to my Sophos box in my VPC so I provisioned another one using the same instructions as before from a Sophos video (https://www.youtube.com/watch?v=7vjgVUUJyIc).

I set up everything ( I think correctly).  I put the box in the public facing side of my VPC (10.0.0.0/24) and gave it 2 NICs.  External NIC is 10.0.0.5 and Internal NIC is 10.1.0.5.  There is an Elastic IP on the instance too.  I added the masquerade rule for 10.0.1.0/24 and added firewall rules for HTTP, HTTPS, ping and NTP.  All works.  I can browse the web, etc. from any machine in the 10.0.1.0/24 subnet.

Here's the problem.  I want to add another subnet (10.0.0.2.0/24) that also needs access to the outside world. So I added a network object in Sophos called Internal .2 Network with 10.0.2.0/24 as the range.  I added that object to another masquerade rule and to the existing firewall rule.  All looked good in the sense that pings were going through the Sophos firewall from 10.0.2.x machines instead of being dropped.  But I cannot browse the internet.  I get "Waiting for www.yahoo.com" for example in any browser (IE, Firefox, Chrome).  I can ping www.yahoo.com with no issues.   And even the dropped packets for port 80 traffic stopped when I added the above rules for 10.0.2.0/24 but the browsers will not bring back any web page.

I installed Packet Sender and send a packet over port 80 to www.google.com.  There and back it responded but no browsing the internet.  I have tried this from 3 machines in the 10.0.2.0/24 space with the same results.

If you do a tracert to www.google.com from a machine in 10.0.1.0/24 or 10.0.2.0/24 the first hop is the internal NIC of the Sophos box (10.0.1.5) as it should be.

Any ideas ?

Thanks

 

Peter 



This thread was automatically locked due to age.
Parents
  • Hi, Peter, and welcome to the UTM Community!

    If the 10.0.1.0/24 subnet is in 'Allowed Networks' for DNS and/or Web Filtering, don't forget to add 10.0.2.0/24 in the same place(s).

    Make sure 'Automatically detect settings' is not selected in 'LAN Settings' in IE.

    If you're still not getting through, try #1 in Rulz.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • Hi, Peter, and welcome to the UTM Community!

    If the 10.0.1.0/24 subnet is in 'Allowed Networks' for DNS and/or Web Filtering, don't forget to add 10.0.2.0/24 in the same place(s).

    Make sure 'Automatically detect settings' is not selected in 'LAN Settings' in IE.

    If you're still not getting through, try #1 in Rulz.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
  • Thank you for your response. I did have both ranges (10.0.1.x and 10.0.2.x) in the Allowed Networks and after watching another video, I consolidated the two into one Network Range object I named Inside Range (10.0.1.1 to 10.0.2.254) and used that in Allowed Networks instead.  After reading your Rulz I also changed the interface on the Inside Range range to Any instead of Internal.

    So I have one masquerade rule showing Inside Range to External and one Firewall rule showing Inside Range to Any (all ports open).  So I continue with your routing suggestions in Rulz.  You wrote to make sure the inside machines (LAN) have a gateway that matches the Internal Address.  I assume you mean the Internal Address object of my UTM which is 10.0.1.5.  All machines in 10.0.1.x are given a gateway of 10.0.1.1 by Amazon.  And machines in 10.0.2.x are given a gateway of 10.0.2.1,  I think this is standard and don't know how i could modify.  Again, all machines when doing a tracert go to 10.0.1.5 as the next hop which is the private side of my UTM.  That is managed by my AWS Route table sending default traffic to the private side of the UTM.

    When I install WireShark on the machines that are not getting to the internet (10.0.2.x) I can see SYN sent over port 80 but no ACK, etc.  And lots of TCP RETRANSMISSIONS.  So I don't think we are getting return traffic.  

    Don't see many logs with data in the UTM. I only have Firewall turned on.  That log shows only white and green, no drops, etc. I can see traffic leaving 10.0.2.x but not coming back.

     

    Thanks in advance.

     

    Peter

     

     

     

  • On the command line of the UTM, you can use tcpdump to see what's arriving from the client and then to see if the SYN leaves the UTM.  If the ACK doesn't come back, then there must be an issue with the AWS configuration.

    Any luck with tcpdump?  Assuming that 10.0.02.101 is the client and the interface is eth2, for example:

    tcpdump -n -i eth2 src 10.0.2.101

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Success !  Thank you Bob for your guidance.  I learned a lot playing around with tcpdump.  I cannot say I fully understand why my fix worked so I will post what happened below in case someone can elucidate.  It was related to an AWS security group applied to the External NIC of the Sophos box.

    • Executed tcpdump to watch traffic on both NICs.  Eth1 (10.0.1.5)/Internal NIC on Sophos and  Eth0 (10.0.0.5)/External NIC on Sophos
    • Observed a full HTTPS round trip for a client behind the Sophos machine.  The test was from a machine in 10.0.1.x subnet which has always worked.  A sample trip from windows client to an internet site (152.19.134.41) would look like something like this.  
      1. ETH1 - 10.0.1.121.59974 > 152.19.134.41.https 
      2. ETH0 - ec2-sophos.59974 > 152.19.134.41.https
      3. ETH0 - 152.19.134.41.https > ec2-sophos.59974
      4. ETH1 - 152.19.134.41.https > 10.0.1.121.59974
    • After reading about the Masquerade rule concept I assume that the source in the above example (10.0.1.121) is swapped out with the External NIC (ec2-sophos) on the way out to internet and swapped again on the way back in.
    • SO...back to my original problem which was "I couldn't browse the web from 10.0.2.x subnet".  When I ran the same tcpdump analysis for traffic from a client (10.0.2.46) in that subnet, I observed that the first 3 steps in the above example completed but not the final step 4.  I assume that ec2-sophos:59974 got swapped out on ETHO with 10.0.2.46:59974 but why did it not continue to that destination?  We have an AWS Security Group on that ETH0 NIC which lets Outbound traffic out on commonly used ports (e.g. 80, 443, etc.) but not dynamically assigned ones like 59974.  When I added ALL ports to that Security Group on that ETHO NIC it all worked.  What baffles me however is why did this Security Group not stop the traffic destined for 10.0.1.121 as detailed in my first example ?  

    Peter

  • Thanks for posting back your results, Peter!

    Instead of using the AWS Security Groups, I just use a wide open one and let the UTM have complete control of firewalling.  I have no idea why traffic to 1.121 was allowed and that to 2.46 was not.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA