cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
791
Views
3
Helpful
7
Replies

ASA Overlapping subnet

chiguy123
Level 1
Level 1

Hi I have a WebVPN setup on my ASA (Software Version 9.12(1)2.  I am having issues setting up email alerts on a Kiwi Syslog server that is logging from the ASA.  Logging is working correctly since I can log on to the Kiwi Syslog server and see the ASA logs. 

The subnet for the WebVPN is 192.168.1.0/24 & the internal SMTP host is 192.168.1.201.

Would the overlapping IPs cause an issue or does this point to NAT not being setup correctly?  I also do not have a specific ACL allowing return SMTP traffic, should I have one?  Please see Wireshark packet capture from when I am trying to connect from an internal VPN host 192.168.1.15, which states "Timeout waiting for client". SMTP Packet capture - 1-21-2025.png       

2 Accepted Solutions

Accepted Solutions

Let start solve overlapping' I see you still use same subnet for both webvpn and DMZ.

MHM

View solution in original post

Thanks for sharing those details. On the diagram that you shared it seems to show the 192.168.1.0/24 subnet defined as the "inside" segment not as the "DMZ", so I am going to assume that that is a typo on the diagram.

Yes you're right, you would need a NAT rule to allow the Syslog server (192.168.1.201) to talk to O365 or anything in the outside world. Otherwise its traffic will never make it to the internet. If the "DMZ_VPN_POOL" object covers all the 192.168.1.0/24 then you can go for it, however, if it only covers part of that subnet then you would need to create a new rule similar to this:

object network DMZ
   subnet 192.168.1.0 255.255.255.0
   nat (DMZ,outside) dyanamic interface

Regarding the packet capture error you shared in your original post, I'm assuming that you tried to install Kiwi services on your laptop (192.168.1.15) and configure the smtp in there. If that was the case, then I think there would be something on your laptop that is blocking the SMTP flow because the error seems to be related to the return traffic from O365 to your laptop. Usually the antivirus/antimalware software would be the first place to look at for this kind of issues, maybe they have some smtp inspection rules that are too aggressive or restrictive.

Finally, if you would like to keep your network design as is having a flat network, then probably I would recommend splitting the VPN clients pool from the rest of the 192.168.1.0/24 subnet. For instance, the range from 192.168.1.200 to 192.168.1.254 would be dedicated for the VPN clients, and nothing on your network should be configured with the IPs from that range.

View solution in original post

7 Replies 7

Sure overlapping make issue.

Change the vpn pool to other subnet like 193.168.2.x 

MHM

I also do not have a specific ACL allowing return SMTP traffic, should I have one? For this it depends' send me PM list all ACL

MHM

No you don't have to worry about creating any ACL rule for the return traffic as that will be allowed by default on the ASA. The ASA will create a state entry for the leaving traffic, and when the traffic comes back the ASA will check its state entries and if there is an existing one it will then allows the return traffic to pass through.

I'm not clear about the packet capture. You mentioned this was taken from a VPN client (192.168.1.15) trying to connect to the SMTP server, is that correct? if so, why the capture shows the return traffic coming from a public IP address (52.96.79.162) instead of the internal SMTP server (192.168.1.201)? where is the internal SMTP server sitting on your network? could you please draw a quick diagram showing where the SMTP is sitting from the ASA perspective? also you mentioned that the issue could be caused by a NAT rule? which NAT rule are you referring to?

The VPN pool must not overlap with anything on your network, otherwise this would cause routing issues from the ASA perspective. However, when you create a VPN pool on the ASA and there are no VPN clients connected yet, or there is no client connected with the IP of an internal resource (in this case I'm referring to the SMTP internal IP 192.168.1.201), then the ASA would not have any route defined for that IP or subnet.

The way how the ASA deals with the VPN pool routes is dynamic and it creates host routes for the connected clients. In your case you have the VPN pool 192.168.1.0/24 defined, so let's say you have 10 VPN clients connected and they were assigned the first 10 IP addresses from the VPN pool. This will result in having 10 host routes with /32 created dynamically on the ASA, these routes will be flushed once the VPN clients are disconnected. So they only last for the duration of the client VPN sessions.

Now let's assume that you also have defined a static route on the ASA towards the 192.168.1.0/24 subnet going via a downstream device. What I think would happen in that case is that the ASA will keep using the host routes for the VPN clients that have been created dynamically, and would also use the 192.168.1.0/24 static route to reach anything in the 192.168.1.0/24 subnet that does not have a host route created. The routing preference will be based on the longest match, so if the traffic is destined to the IP 192.168.1.201 and this IP happened not to be taken by any VPN client then I think the ASA in this case will use the defined static route towards the 192.168.1.0/24 subnet. I'm not saying that having an IP addressing overlap between the VPN clients pool and the internal resources would be ok, but I'm trying to break it down a bit and trying to locate the causing issue. Best practice will still be to have a non-used range/subnet on your network that will be dedicated for the VPN clients.

chiguy123
Level 1
Level 1

Please see attachment of network diagram. 

The packet capture was taken when I tried to set up SolarWinds Kiwi Syslog server and received a connection error after I put in the smtp login information. 

The 52.96.79.162 address is one of Microsoft’s “smtp.office365.com” addresses.  The 192.168.1.201 address is the local host where SolarWinds Kiwi Syslog is installed to provide logging for the ASA, the 192.168.1.15 host is my laptop on the VPN.   

The reason why I brought up NAT was because I didn’t see DMZ in the last NAT statement in our configuration using the DMZ interface - 192.168.1.0./24, I only saw the ones below.

 

nat (DMZ,outside) source static any any destination static DMZ_VPN_POOL DMZ_VPN_POOL no-proxy-arp route-lookup

object network DMZ_VPN_POOL

 nat (outside,outside) dynamic interface

object network inside

 nat (inside,outside) dynamic interface

 

Should the DMZ_VPN_POOL NAT statement be configured as shown below since the DMZ interface is 192.168.1.0./24 & the outside is the 52.X.X.X?

object network DMZ_VPN_POOL

nat (DMZ,outside) dynamic interface

Let start solve overlapping' I see you still use same subnet for both webvpn and DMZ.

MHM

Thanks I have asked my Team to see if we can put them on different subnets.  Since we have a flat network what would be the best way to put them on separate non-overlapping subnets?  We only have one network circuit and no other network devices to provide the needed layer 3 boundaries.   

Thanks for sharing those details. On the diagram that you shared it seems to show the 192.168.1.0/24 subnet defined as the "inside" segment not as the "DMZ", so I am going to assume that that is a typo on the diagram.

Yes you're right, you would need a NAT rule to allow the Syslog server (192.168.1.201) to talk to O365 or anything in the outside world. Otherwise its traffic will never make it to the internet. If the "DMZ_VPN_POOL" object covers all the 192.168.1.0/24 then you can go for it, however, if it only covers part of that subnet then you would need to create a new rule similar to this:

object network DMZ
   subnet 192.168.1.0 255.255.255.0
   nat (DMZ,outside) dyanamic interface

Regarding the packet capture error you shared in your original post, I'm assuming that you tried to install Kiwi services on your laptop (192.168.1.15) and configure the smtp in there. If that was the case, then I think there would be something on your laptop that is blocking the SMTP flow because the error seems to be related to the return traffic from O365 to your laptop. Usually the antivirus/antimalware software would be the first place to look at for this kind of issues, maybe they have some smtp inspection rules that are too aggressive or restrictive.

Finally, if you would like to keep your network design as is having a flat network, then probably I would recommend splitting the VPN clients pool from the rest of the 192.168.1.0/24 subnet. For instance, the range from 192.168.1.200 to 192.168.1.254 would be dedicated for the VPN clients, and nothing on your network should be configured with the IPs from that range.

Review Cisco Networking for a $25 gift card