Help w/ tunnel - NAT, routing

Hi, and welcome to the User BB!

I don't think I'm following your description.  You say "Everything is working great..." - does that mean that devices in the public and private subnets can communicate with each other?  - that you can communicate to your public network from your office?

You say the tunnel established fine - does that mean you get other traffic, just not pings?

If you click on 'Site-to-Site' in WebAdmin, you are presented with a Status page.  Please click on [Go Advanced] below and attach a picture of the expanded status.  Obfuscate the public IPs if you wish by blanking the middle two octets.

How is your VPC defined - with subnets 10.1.2.0/24 and 10.1.3.0/24 inside 10.1.0.0/16?

If a masq rule had solved this problem, it might have been an indication of a violation of #3 in Rulz.

Cheers - Bob

I apologize, I should have been more clear. "Working great" is pretty subjective!  [:)]  We set up a public and private interface and have configured many devices on the private interface that can talk to each other and can talk to the public interface.  Firewall rules, NAT, WAF, all configured and working perfectly.  We're actually using the 30 day trial AMI instance and at this point there is no doubt that we'll be sticking with it.  

As for the tunnel, it established without a problem but isn't passing any traffic - or at least I don't see anything since I can't ping any hosts in the remote subnet.

Screenshot attached of what I think you asked for.  I didn't see anything about advanced?  

The VPC is defined as 10.0.0.0/8, with a single subnet for this network of 10.1.2.0/24.

From a troubleshooting perspective the remote host is at 192.168.111.118 and is open for a number of services, and will respond to pings.  From within our 10.1.2.0/24 subnet we're trying to ping the remote host at 10.1.3.118 but it's failing at the UTM.

Thanks again for the help.

Pinging is regulated on the 'ICMP' tab of 'Firewall', so if your only test was a ping, that might be an issue.

If the VPC doesn't have 10.1.3.0/24 as a defined subnet, I don't understand how that subnet is recognized by the VPC.

Is the remote host at 192.168.111.118 or at 10.1.3.118?  If the IPsec tunnel is limited to 10.1.2.0/24, why should the Cisco route traffic for 10.1.3.0/24 through it?

Cheers - Bob

Bob, 

Perhaps my understanding of how the tunnel works is completely wrong, and therein may be the answer.  Please check my understanding:

The remote network is 192.168.111.0/24, the local tunnel subnet is 10.1.3.0/24.  If the remote host is 192.168.111.118, I thought that I could reach it by connecting to 10.1.3.118 - that is to say that the 256 IPs in the 192.168.111.x block are mapped locally to my 10.1.3.x subnet that I defined for this tunnel.  Is that fundamentally incorrect?

So, by that thinking, I was under the impression that even though the subnet of the Internal interface on the UTM is 10.1.2.0/24, any traffic for 10.1.3.x would use the UTM as the gateway, which would properly route it over the tunnel to the remote end.  I didn't think that the subnet of the Internal interface actually had to include the subnet of the tunnel since - I thought - routing would be accomplished by the UTM as the default gateway.  Am I way off?

On the Cisco (remote) side they have our private network configured as 10.1.3.0/24, so I "assumed" the same thing would happen - traffic for 10.1.3.5 wouldn't be a part of their 192.168.111.0/24 subnet, it would route it to the Cisco ASA as the default GW, and the ASA would route it over the tunnel to our end.

As far as pings go, I allowed everything in the firewall tab but nothing worked.  In reality we've been trying to telnet to specific open ports on our application, too, but that hasn't worked.

The OVERALL VPC that these machines are in is 10.0.0.0/8, but this particular interface (the UTM and some servers) are only assigned to the 10.1.2.0/24 subnet.

Thanks for sticking with me,
Shaun

The remote network is 192.168.111.0/24, the local tunnel subnet is 10.1.3.0/24. If the remote host is 192.168.111.118, I thought that I could reach it by connecting to 10.1.3.118 - that is to say that the 256 IPs in the 192.168.111.x block are mapped locally to my 10.1.3.x subnet that I defined for this tunnel. Is that fundamentally incorrect?

Well, I'm still confused by your explanation, Shaun, so I guess there may well be a misunderstanding. [:S]  I'm still unclear on where "local" and "remote" are - is there a VPC, an Office and a Data Center, which subnets are defined where and where is the Cisco?  What is the purpose of the VPN connection?  Also, there may be a subnet overlap between the VPC definition and the Cisco site.  Sorry, I'm a visual-tactile, so until I can get a picture in my mind or see a diagram, my intuition is short-circuited.

The IPsec tunnel just connects subnets in two locations to each other.  There is no address translation.

Cheers - Bob