topic Re: all internal interfaces cannon communicate in Network Security

all internal interfaces cannon communicate

evinogradov — Mon, 11 Mar 2019 16:46:40 GMT

I need help. I have ASA 55xx with the multiple public IPs setup on outside interface via PPPoE. I have most common activity on all my local interfaces (nated to statics outside) like www, 443, pop3, etc.

Here is config (I removed unnecessary)

names

name 192.168.2.10 SQL_server
!
interface Vlan1
nameif inside
security-level 100
ip address 192.168.1.1 255.255.255.0
!
interface Vlan2
nameif outside
security-level 0
pppoe client vpdn group ATT
ip address pppoe
!
interface Vlan3
nameif sql
security-level 100
ip address 192.168.2.1 255.255.255.0
!
interface Vlan4
nameif acc_protected
security-level 100
ip address 192.168.0.1 255.255.255.0
!
!
same-security-traffic permit inter-interface
same-security-traffic permit intra-interface
access-list outside_access_in extended permit tcp any any eq 1433
access-list outside_access_in extended permit tcp any any eq ftp
access-list outside_access_in extended permit tcp any any eq 3001
access-list outside-entry extended permit tcp any host xx.xxx.xxx.230 eq 1433
access-list inside_mpc extended permit tcp any any eq www inactive
access-list inside_mpc extended permit tcp any any eq 8080 inactive
access-list DMZtoInside extended permit tcp host 192.168.0.1 host SQL_server eq 1433
access-list DMZtoacc_protected extended permit tcp host SQL_server host 192.168.0.1 eq 1433
!
!
nat-control
global (outside) 1 xx.xxx.xxx.227 netmask 255.255.255.255
global (outside) 2 xx.xxx.xxx.230 netmask 255.255.255.255
global (outside) 3 xx.xxx.xxx.229 netmask 255.255.255.255
nat (inside) 1 0.0.0.0 0.0.0.0
nat (sql) 2 SQL_server 255.255.255.255
nat (acc_protected) 3 0.0.0.0 0.0.0.0
static (sql,outside) tcp interface 1433 SQL_server 1433 netmask 255.255.255.255
static (sql,outside) tcp interface ftp SQL_server ftp netmask 255.255.255.255
access-group outside_access_in in interface outside
route outside xx.xxx.xxx.227 255.255.255.255 192.168.1.1 1
route outside xx.xxx.xxx.230 255.255.255.255 192.168.2.1 1
route outside 0.0.0.0 0.0.0.0 192.168.1.1 1
route outside xx.xxx.xxx.229 255.255.255.255 192.168.0.1 1
!
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 512
policy-map type inspect http http_inspection_policy
parameters
protocol-violation action drop-connection
match request method connect
drop-connection log
class AppHeaderClass
drop-connection log
class BlockDomainClass
reset log
class BlockURLsClass
reset log
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
policy-map inside-policy
class httptraffic
inspect http http_inspection_policy
!
service-policy global_policy global
service-policy inside-policy interface inside
smtp-server xx.xxx.xxx.195
prompt hostname context
Cryptochecksum:6ea76e35e66277a1cc48abc1e5bc049b
: end

Problem:

all remote clients(from cloud) can contact and communicate with SQL_server (see names). However, there are no communications from acc-protected interface to it. Also all internal interfaces cannot see each other.

Re: all internal interfaces cannon communicate

Ivan Martinon — Tue, 08 Dec 2009 23:38:31 GMT

Communication between interfaces with the same security level is blocked by default, you need to enable it with the command "same-security-traffic permit inter-interface" along with the proper nat and access control rules.

Re: all internal interfaces cannon communicate

evinogradov — Wed, 09 Dec 2009 17:47:14 GMT

Ivan, did you see my config before posting some average recommendation?

Isn't it enough: "same-security-traffic permit inter-interface". Do I need it double?

Re: all internal interfaces cannon communicate

Ivan Martinon — Wed, 09 Dec 2009 17:56:40 GMT

My friend I was trying to help, my bad for not reading the whole config and just focusing on the BOLD text, as for your problem, I see that you have a nat applied to the acc-protected interface, having this nat here would require you to have a global on any egress interface, have you tried using a static nat to that server on the acc-protected interface? Can you maybe get some logs that wold reflect what the firewall is doing with the packet? Hope this is not as average as the other..

Re: all internal interfaces cannon communicate

evinogradov — Wed, 09 Dec 2009 19:00:29 GMT

Ivan, I appriciate for such a quick response. Exactly, there are no visible issues with nat. I tried everithing: static on sql server, static to domain controller on inside interface instead of global. Could just suprise me with someting that I didn't try. I think that, IMHO, the problem related to ppp outside. First, it's obtaining xx.xxx.xxx.230 public IP by pppoe

ciscoasa#sh interface outside

Interface Vlan2 "outside", is up, line protocol is up
Hardware is EtherSVI
MAC address 0024.14f3.9a66, MTU 1492
IP address xx.xxx.xxx.230, subnet mask 255.255.255.255
Traffic Statistics for "outside":
10532229 packets input, 8427437415 bytes
4093500 packets output, 1009222741 bytes
280315 packets dropped
      1 minute input rate 13 pkts/sec, 12924 bytes/sec
      1 minute output rate 5 pkts/sec, 1830 bytes/sec
      1 minute drop rate, 0 pkts/sec
      5 minute input rate 17 pkts/sec, 14808 bytes/sec
      5 minute output rate 7 pkts/sec, 2070 bytes/sec
      5 minute drop rate, 0 pkts/sec
This static IP belongs to outside interface. All other statics outside I get manually by the global pools. After, I can't apply any static nat to the global pools. It's working but under global rules. So, kind of confising for myself.

Re: all internal interfaces cannon communicate

Ivan Martinon — Wed, 09 Dec 2009 19:09:43 GMT

Well first of all we need to find out how are those hosts looking for this server, what IP address are they using to reach it? Can you ping this ip address? try turning on logs on the ASA when pinging this ip address and let me know what is the message you get there my point is first we need to confirm if it is due to a missing translation or something else but for that we need the logs and find out what is the correct symptom.

As for the nat I meant something like this

static (sql,acc-protected) tcp interface 1433 SQL_server 1433 netmask 255.255.255.255
static (sql,acc-protected) tcp interface ftp SQL_server ftp netmask 255.255.255.255

Has this been applied?

As well please go ahead and try this command on the ASA and paste the output here:

packet-tracer input interface acc-protected tcp 1024 192.168.2.10 1433 detailed

Re: all internal interfaces cannon communicate

evinogradov — Wed, 09 Dec 2009 20:06:57 GMT

Ivan, here is my likely message for the last few days after

static (sql,acc_protected) tcp interface 1433 SQL_server 1433 netmask 255.255.255.255

P.S. I dont need FTP here

#packet-tracer input acc_protected tcp 192.168.0.1 1024 192.168.2.10 1433 detailed

Phase: 1
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow

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

Phase: 3
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0x41c9930, priority=500, domain=permit, deny=true
hits=11, user_data=0x6, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip=192.168.0.1, mask=255.255.255.255, port=0
dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Result:
input-interface: acc_protected
input-status: up
input-line-status: up
output-interface: sql
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

or with

ip verify reverse-path interface acc_protected

Phase: 1
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow

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

Phase: 3
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 192.168.0.1 255.255.255.255 identity

Result:
input-interface: acc_protected
input-status: up
input-line-status: up
output-interface: NP Identity Ifc
output-status: up
output-line-status: up
Action: drop
Drop-reason: (rpf-violated) Reverse-path verify failed

Re: all internal interfaces cannon communicate

evinogradov — Sun, 13 Dec 2009 02:54:52 GMT

resolved.

!
interface Vlan2
nameif outside
security-level 0
pppoe client vpdn group ATT
ip address pppoe setroute - default route from ISP

Ivan, thanks for participation.