topic interface communication issues in Network Security

interface communication issues

heather.burke — Mon, 11 Mar 2019 18:53:34 GMT

I'm still having trouble getting communication between all of my interfaces. With help from this forum, I was able to connect out to the internet and from that I learned how to replicate taht to the third interface. However, I still have not been able to establish bi-directional connectivity. I started all over again, and started working with just the connectivity between the inside interface and the DMZ interface. I am completely unable to ping from the DMZ into the internal interface. I set all the security levels the same, allowed everything in the access lists and still nothing. I've tried dynamic nat rules using PAT, and nothing. The same set up works fine to go the other way, from internal to DMZ, but not vice versa. Static bidirectional NATs have the same problem....they will work one way to ping from inside out, but not back.

I've allowed ICMP through all the interfaces through the command line (which seemed to delte all the other access rules I had in place)

Anyone have any ideas what else I can try? I've tried different switches, and even gone so far as to change around the interface setup, but to no avail.

Re: interface communication issues

Marcin Latosiewicz — Tue, 12 Oct 2010 22:25:50 GMT

Heather,

Post the config, we'll have a look 🙂

Btw if you interfaces share same surity level just remember to add "same-security permit inter" command.

Marcin

Re: interface communication issues

heather.burke — Thu, 14 Oct 2010 15:07:39 GMT

Sorry for the delay. Here is the config (in its recent incarnation, anyway):

!
interface Ethernet0/0
description EXTERNAL
nameif OUTSIDE
security-level 0
ip address 10.10.204.99 255.255.255.0
!
interface Ethernet0/1
description INTERNAL INTERFACE
nameif INSIDE
security-level 100
ip address 192.168.2.1 255.255.255.0
!
interface Ethernet0/2
description DMZ INTERFACE
nameif DMZ
security-level 100
ip address 172.20.204.99 255.255.255.0
!
interface Ethernet0/3
description LAN/STATE Failover Interface
management-only
!
interface Management0/0
nameif management
security-level 99
ip address 192.168.1.1 255.255.255.0
management-only
!

access-list INSIDE_access_in extended permit tcp any any eq www inactive
access-list INSIDE_access_in extended permit object-group ALLSERVICES 10.10.204.0 255.255.255.0 object 172.20.204.0
access-list INSIDE_access_in extended permit udp any any eq domain
access-list INSIDE_access_in remark ALLOWS ANY INTERNAL HOST TO CONNECT TO INTERNET
access-list INSIDE_access_in extended permit object-group WebServicePlus 192.168.204.0 255.255.255.0 any
access-list INSIDE_access_in remark ALLOW ADMINS TO PING, TRACEROUTE, ETC. TO ANY DESTINATION.
access-list INSIDE_access_in extended permit icmp object-group Admins any
access-list INSIDE_access_in remark ALLOW INSIDE HOSTS TO ACCESS TRD - HELPSTAR USING SEVERAL SERVICES.
access-list INSIDE_access_in extended permit object-group HELPSTARGROUP 192.168.204.0 255.255.255.0 object HELPSTAR
access-list INSIDE_access_in extended permit object-group ALLSERVICES object-group Admins interface management
access-list INSIDE_access_in remark test rule for web connectivity.
access-list INSIDE_access_in extended permit object-group WebServicePlus 192.168.2.0 255.255.255.0 any
access-list INSIDE_access_in remark ALLOWS SMTP OUT
access-list INSIDE_access_in extended permit object-group MailServices object obj-192.168.204.0 any
access-list INSIDE_access_in extended permit object-group ALLSERVICES any 172.20.204.0 255.255.255.0
access-list INSIDE_access_in extended permit object-group ALLSERVICES any interface DMZ
access-list INSIDE_access_in extended permit object-group DMZSQLSERVICES 192.168.204.0 255.255.255.0 172.20.204.0 255.255.255.0
access-list INSIDE_access_in extended permit object-group ALLSERVICES any any
access-list OUTSIDE_access_in_1 extended permit object-group HTTPHTTPS 10.10.204.0 255.255.255.0 any
access-list OUTSIDE_access_in_1 remark ALLOW SLO HOSTS TO ACCESS OHD FOR TESTING
access-list OUTSIDE_access_in_1 extended permit object-group HTTPHTTPS object-group SLO object OHD
access-list OUTSIDE_access_in_1 remark ALLOW ACCESS FROM EXTERNAL IP ADDRESS TO INTERNAL IP ADDRESS ON OH
access-list OUTSIDE_access_in_1 extended permit tcp object OH.US object OH-NIC2 eq www
access-list OUTSIDE_access_in_1 extended permit icmp host 10.10.7.1 any
access-list OUTSIDE_access_in_1 extended permit object-group ALLSERVICES object 172.20.204.0 164.64.204.0 255.255.255.0
access-list OUTSIDE_access_in_1 extended permit object-group ALLSERVICES any any
access-list OUTSIDE_access_in remark ALLOW SLO TESTERS TO COMMUNICATE WITH OHD.
access-list OUTSIDE_access_in remark ALLOW SLO TESTERS TO COMMUNICATE WITH OHD.
access-list OUTSIDE_access_in extended permit object-group HTTPHTTPS 10.10.204.64 255.255.255.192 host 192.168.204.55
access-list DMZ_access_in remark ALLOWS INTERNAL HOSTS TO CONNECT TO MAINFRAME
access-list DMZ_access_in extended permit object-group MainframeServices 192.168.204.0 255.255.255.0 any
access-list DMZ_access_in remark ALLOW INTERNAL HOSTS TO CONNECT TO DMZ/PERIMETER
access-list DMZ_access_in extended permit object-group ALLSERVICES 192.168.204.0 255.255.255.0 172.20.204.0 255.255.255.192
access-list DMZ_access_in extended permit object-group ALLSERVICES object-group DMZCOMPUTERS any
access-list DMZ_access_in remark ALLOW DMZ COMPUTERS TO TALK TO INTERNAL
access-list DMZ_access_in extended permit object-group INTERNALSERVICES object-group DMZCOMPUTERS 192.168.204.0 255.255.255.0
access-list DMZ_access_in remark ALLOWS DMZ SQL SERVERS TO TALK TO INSIDE HOSTS
access-list DMZ_access_in extended permit object-group DMZSQLSERVICES object-group DMZSQLSERVERS 192.168.204.0 255.255.255.0
access-list DMZ_access_in remark ALLOWS ALL DMZ SERVERS TO BE BACKED UP VIA OHBK.
access-list DMZ_access_in extended permit object-group BACKUPEXEC object DMZNETWORK 192.168.204.0 255.255.255.0
access-list DMZ_access_in remark ALLOW PINGBACK FROM DMZ
access-list DMZ_access_in extended permit icmp object 172.20.204.0 any
access-list DMZ_access_in extended permit object-group ALLSERVICES 172.20.204.0 255.255.255.0 192.168.204.0 255.255.255.0
access-list DMZ_access_in extended permit object-group DMZSQLSERVICES 172.20.204.0 255.255.255.0 object OH
access-list DMZ_access_in extended permit object-group ALLSERVICES host 172.20.204.41 object OH-NIC2
access-list DMZ_access_in extended permit object-group ALLSERVICES 172.20.204.0 255.255.255.0 192.168.2.0 255.255.255.0
access-list INSIDE_nat0_outbound extended permit ip any 192.168.204.240 255.255.255.240
access-list global_access extended permit object-group ALLSERVICES any any
access-list ICMPACL extended permit icmp any any
pager lines 24
logging enable
logging console emergencies
logging asdm informational
logging class auth console errors
logging class sys console errors
mtu OUTSIDE 1500
mtu INSIDE 1500
mtu DMZ 1500
mtu management 1500
ip local pool VPBNIPPOOL 192.168.204.240-192.168.204.250 mask 255.255.255.0
ip local pool VPNTESTPOOL 192.168.2.100-192.168.2.114 mask 255.255.255.240
failover
failover lan unit primary
failover lan interface HEARTBEAT Ethernet0/3
failover link HEARTBEAT Ethernet0/3
failover interface ip HEARTBEAT 10.1.1.1 255.255.255.0 standby 10.1.1.2
icmp unreachable rate-limit 1 burst-size 1
icmp permit any OUTSIDE
icmp permit any echo-reply OUTSIDE
icmp permit any INSIDE
icmp permit any echo-reply INSIDE
icmp permit any DMZ
icmp permit any echo-reply DMZ
icmp permit any management
icmp permit any echo-reply management
asdm image disk0:/asdm-634.bin
no asdm history enable
arp timeout 14400
nat (INSIDE,DMZ) source static 192.168.2.0 DMZNATPOOL destination static 172.20.204.0 172.20.204.0
!
object network OBJ-192.168.204.0
nat (INSIDE,OUTSIDE) dynamic interface
object network TESTOBJ-192.168.204.0
nat (INSIDE,DMZ) dynamic interface
access-group ICMPACL in interface OUTSIDE
access-group ICMPACL in interface INSIDE
access-group ICMPACL in interface DMZ
access-group ICMPACL in interface management
access-group global_access global
route OUTSIDE 0.0.0.0 0.0.0.0 10.10.204.65 1

Re: interface communication issues

praprama — Thu, 14 Oct 2010 15:39:30 GMT

Hi,

So based on your original post i assume youa re still facing issues between inside to DMZ, that is, pings from inside to DMZ works but not from DMZ to inside. Can you also paste the output of the following packet-tracer when initiating a ping from the DMZ to the inside:

packet-tracer input DMZ icmp 8 0 detailed

Thanks and Regards,

Prapanch

Re: interface communication issues

Marcin Latosiewicz — Thu, 14 Oct 2010 15:49:35 GMT

Heather,

There's a mix of different NATs.

What would you like to achieve in the end?

Do you want to NAT or PAT users going from inside to dmz or the other way around?

I don't see same-security permit inter-interface in configuration.

Marcin

Re: interface communication issues

heather.burke — Thu, 14 Oct 2010 16:03:22 GMT

When I do the packet tracer via ASDM it says that the packet is successful....however, the reality is that it is not. (I'm not sure if that's true with this config itself, since I've changed it so many times lately!)

I will go do a CLI one and post it for you

Re: interface communication issues

heather.burke — Thu, 14 Oct 2010 16:10:34 GMT

Ultimately, we want the inside to get out to the Internet, the outside to get inside to one specific server, and the DMZ and Inside to communicate both ways. Sadly, the person who set up this network left the web server inside and put its database server in the DMZ... My plan is to eventually get these put correctly, but that changeover will be a bit complicated, so first I am trying to get the new ASA to work as it is.

The way I understand it, PAT is fickle for bidirectional traffic, so static NAT seems to be what you would need to use for that. Is that correct?

I believe that the same security box is checked in the ASDM, though it has never made any difference. Ultimately, the DMZ SHOULD be a different security level (were it truly a DMZ, anyway)

Re: interface communication issues

heather.burke — Thu, 14 Oct 2010 16:36:20 GMT

here is the result of the trace. I changed around teh existing NAT to go the other direction (nat (DMZ,INSIDE) source static 172.20.204.0 TESTNETNATPOOL destination static 192.168.2.0 192.168.2.0) to demonstrate what I was talking about. The packet tracer says successful, but it is not in RL.

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 192.168.2.0 255.255.255.0 INSIDE

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group ICMPACL in interface DMZ
access-list ICMPACL extended permit icmp any any
Additional Information:

Phase: 3
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 4
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (DMZ,INSIDE) source static 172.20.204.0 TESTNETNATPOOL destination static 192.168.2.0 192.168.2.0
Additional Information:
Static translate ONGARDDBC1/0 to 192.168.2.55/0

Phase: 6
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 1024, packet dispatched to next module

Result:
input-interface: DMZ
input-status: up
input-line-status: up
output-interface: INSIDE
output-status: up
output-line-status: up
Action: allow

Re: interface communication issues

praprama — Thu, 14 Oct 2010 17:07:09 GMT

Hi,

Hmmm.. That's interesting.. Can you post the output of "show run object" and "show run object-group". To be specific, I just would like to know what IP addresses are configured under the two groups TESTNETNATPOOL and DMZNATPOOL? Also, what IP address does the name ONGARDDBC1 represent?

Regards,

Prapanch

Re: interface communication issues

heather.burke — Thu, 14 Oct 2010 17:37:04 GMT

ok both of those pools are just a group of about 5 addresses on each of the subnets. I had tried doing a static using the interface address, but got warning messages. I wasn't sure if I should be assigning a one to one address, from the old subnet to the new subnet. I worried that doing this might cause issues if more than one connection was established at once, but I am not sure if that is true. ( When I do a pool or just one address, the result is the same, though.) DBC1 is the translation of 172.20.204.41.

Re: interface communication issues

praprama — Fri, 15 Oct 2010 15:26:20 GMT

Hey,

Apologies for the late response. Hmmm that's interesting. So the object named 172.20.204.0 specifies the entire DMZ subnet right? In that case, you are trying create a static NAT for the entire DMZ subnet to a pool of 5 IP addresses on the Inside. That unfortunately, will not work.

In general, when we perform a static translation for an entore subnet, we generally create a mapped subnet of equal size, that is, in our case it will be 172.20.204.0/24 will mapped to x.x.x.0/24 while in our case instead of an entore /24 subnet, we just have a pool of 5 IP addresses. I am not really sure of the packet-tracer output in this case over here.

Is there any particular reason you are performing that NAT? Instead, if it's alright, why don't you just map the DMZ subnet to itself by having the below command:

nat (DMZ,INSIDE) source static 172.20.204.0 172.20.204.0 destination static 192.168.2.0 192.168.2.0

Regards,

Prapanch

Re: interface communication issues

heather.burke — Fri, 15 Oct 2010 17:25:10 GMT

No, there is no particular reason. It has just been part of my troubleshooting process. I will give your suggestion a try. I thought that I had tried soemthing like it, and got an error message or had it not work, but at this point I've started duplicating my efforts out of frustration anyway!

Ok, I tried it and it won't allow the whole netwrok because of some addresses assigned to a VPN pool that was set up by another agency yesterday (too many chefs)

However, I just think I learned something. This whole time I have been operating on a test net, to configure the firewall before taking it live, and enable me to run tests without having to stay late every night. However, I had elected to plug into the actual switch that is really hosting the current DMZ. (Assuming that it would know to route the traffic from it's source back through the test firewall Whixh was the case going out, but never coming back in) However, I am starting to believe that it is just too confusing for it. We just experienced a hiccup in our normal communication with those servers (not related to these tests) and during that hiccup, I was able to ping from the DMZ into my test net. (using a dynamic PAT I had just set up for the hundreth time) However, as quickly as it worked, it stopped working. (and that moment coincided exactly with the production issue) I am going to try seeing if I can configure a wholly seperate test DMZ subnet and see if I can confirm this.

Does this sound to you like it could be causing the communication issue?

Re: interface communication issues

heather.burke — Fri, 15 Oct 2010 19:22:15 GMT

hmm well that has not ended up being the silver bullet that I hoped. I still can't ping out of my test DMZ net. (I can't ping all the way in yet either, just to the test switch, but for now that will have to do)

Re: interface communication issues

praprama — Sat, 16 Oct 2010 14:55:20 GMT

Hi,

Could you draw out a line topology for us? it is a little confusing with the switch now. I am not really sure where the switch is and from where to where pings are working or not.

Also, i think it's high time we started using captures on the DMZ and inside interfaces. Please do apply those and let me know how it looks.

https://supportforums.cisco.com/docs/DOC-1222

Regards,

Prapanch

Re: interface communication issues

Maykol Rojas — Sat, 16 Oct 2010 19:05:48 GMT

Hello Heather

This is Mike, Please take a look below

The NAT sould look like this

Object Internal-Net
subnet 192.168.2.0

Object DMZ-Net
Subnet 172.20.204.0

On global configuration mode
nat (inside,dmz) source static Internal-Net Internal-Net destination DMZ-Net DMZ-Net

Try that and then send us the packet tracer from inside to the DMZ and then from the DMZ to the inside. Dynamic nat is not quite the scenario that you need, I guess you will need to see the real IP of the servers located on the DMZ and the DMZ servers should be able to see the real IP of the Inside hosts. So No nat seems like the best practice here.

I have attached a quick drawing of what I think is the current scenario, please let us know if that is correct

Thanks!

Mike