Trouble with HTTP traffic from VPC

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

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

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

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