cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1491
Views
5
Helpful
25
Replies

ASA 1150 FPWR - Does not block bgp to device

Hej
I am testing what traffic to allow and block directly with the block. I have the below configuration that should in theory block all traffic to device from a neighbor including BGP. But regardless the BGP session stays up .

I am wondering what I am missing

access-list DENY-ALL extended deny ip any any 
access-list DENY-ALL extended deny tcp any any 

access-group DENY-ALL in interface SD-WAN-1 control-plane
access-group DENY-ALL in interface SD-WAN-1

interface Ethernet1/10.6
 vlan 6
 nameif SD-WAN-1
 security-level 0
 zone-member SD-WAN-1
 ip address 172.16.6.1 255.255.255.0 standby 172.16.6.2 

router bgp 8989
 bgp log-neighbor-changes
 address-family ipv4 unicast
  neighbor 172.16.6.3 remote-as 666
  neighbor 172.16.6.3 activate
  no auto-summary
  no synchronization

 

# show bgp summary 
BGP router identifier 172.16.66.1, local AS number 8989
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
172.16.6.3      4          666 236     195            3    0    0 03:33:36  0       
172.16.7.3      4          666 237     195            3    0    0 03:33:36  0   

################################################################
################################################################
# show bgp neighbors 172.16.6.3

BGP neighbor is 172.16.6.3,  context single_vf,  remote AS 666, external link
  BGP version 4, remote router ID 172.16.6.3
  BGP state = Established, up for 03:34:08
  Last read 00:00:10, last write 00:00:51, hold time is 180, keepalive interval is 60 seconds
  Neighbor sessions:
    1 active, is not multisession capable (disabled)
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Four-octets ASN Capability: advertised and received
    Address family IPv4 Unicast: advertised and received
    Multisession Capability: 
  Message statistics:
    InQ depth is 0
    OutQ depth is 0
    
                   Sent       Rcvd
    Opens:         1          1         
    Notifications: 0          0         
    Updates:       1          1         
    Keepalives:    193        235       
    Route Refresh: 0          0         
    Total:         195        237       
  Default minimum time between advertisement runs is 30 seconds

 For address family: IPv4 Unicast
  Session: 172.16.6.3
  BGP table version 3, neighbor version 3/0
  Output queue size : 0
  Index 3
  3 update-group member
                           Sent       Rcvd
  Prefix activity:         ----       ----
    Prefixes Current:      2          0         
    Prefixes Total:        4          0         
    Implicit Withdraw:     2          0         
    Explicit Withdraw:     0          0         
    Used as bestpath:      n/a        0         
    Used as multipath:     n/a        0         

                                Outbound    Inbound
  Local Policy Denied Prefixes: --------    -------
    Total:                       0          0         
  Number of NLRIs in the update sent: max 2, min 0

  Address tracking is enabled, the RIB does have a route to 172.16.6.3
  Connections established 5; dropped 4
  Last reset 03:34:09, due to User reset of session 1
  Transport(tcp) path-mtu-discovery is enabled
  Graceful-Restart is disabled
25 Replies 25

fw01-tgl-cph(config)# show version

Cisco Adaptive Security Appliance Software Version 9.16(2)3
SSP Operating System Version 2.10(1.172)
Device Manager Version 7.16(1)

 

Before trying ping
fw01-tgl-cph(config)# show access-list DENY-ALL
access-list DENY-ALL; 2 elements; name hash: 0xfa20fecd
access-list DENY-ALL line 1 extended deny ip any any (hitcnt=59) 0x42b7c013
access-list DENY-ALL line 2 extended deny tcp any any (hitcnt=0) 0xba274680


I can ping from Remote device to ASA and it does not increase the hitcnt. I do not have icmp permit on that interface for the record as well.

If I try to telnet then telnet fails and I see incease in hitcnt

fw01-tgl-cph(config)# show access-list DENY-ALL
access-list DENY-ALL; 2 elements; name hash: 0xfa20fecd
access-list DENY-ALL line 1 extended deny ip any any (hitcnt=61) 0x42b7c013
access-list DENY-ALL line 2 extended deny tcp any any (hitcnt=0) 0xba274680

can you add Log to your acl and check if traffic hit the ACL or not
MHM


It looks like It denies the TCP connection, but after 3 min the remote host uses a different port 35858 and connection establishes.

fw01-tgl-cph(config)# show logging
Syslog logging: enabled
Facility: 20
Timestamp logging: disabled
Hide Username logging: enabled
Standby logging: disabled
Debug-trace logging: disabled
Console logging: disabled
Monitor logging: disabled
Buffer logging: level debugging, 52 messages logged
Trap logging: disabled
Permit-hostdown logging: disabled
History logging: disabled
Device ID: disabled
Mail logging: disabled
ASDM logging: disabled
ng buffered 6'
%ASA-5-111008: User 'admin' executed the 'logging buffered 7' command.
%ASA-5-111010: User 'admin', running 'CLI' from IP 10.255.0.141, executed 'logging buffered 7'
%ASA-7-111009: User 'admin' executed cmd: show running-config logging
%ASA-6-106015: Deny TCP (no connection) from 172.16.6.3/33419 to 172.16.6.1/179 flags PSH ACK on interface SD-WAN-1
%ASA-7-710005: TCP request discarded from 172.16.6.3/33419 to SD-WAN-1:172.16.6.1/179
%ASA-7-111009: User 'admin' executed cmd: show logging
%ASA-6-302014: Teardown TCP connection 23574 for SD-WAN-1:172.16.6.3/58074 to identity:172.16.6.1/179 duration 0:01:39 bytes 323 Host is removed
%ASA-7-609002: Teardown local-host SD-WAN-1:172.16.6.3 duration 0:01:39
%ASA-5-111008: User 'admin' executed the 'clear conn all address 172.16.6.3' command.
%ASA-3-418018: neighbor 172.16.6.3 Down Peer closed the session
%ASA-3-418018: neighbor 172.16.6.3 IPv4 Unicast topology base removed from session Peer closed the session
%ASA-6-106015: Deny TCP (no connection) from 172.16.6.3/58074 to 172.16.6.1/179 flags PSH ACK on interface SD-WAN-1
%ASA-7-710005: TCP request discarded from 172.16.6.3/58074 to SD-WAN-1:172.16.6.1/179
%ASA-6-106015: Deny TCP (no connection) from 172.16.6.3/58074 to 172.16.6.1/179 flags PSH ACK on interface SD-WAN-1
%ASA-7-710005: TCP request discarded from 172.16.6.3/58074 to SD-WAN-1:172.16.6.1/179
%ASA-6-106015: Deny TCP (no connection) from 172.16.6.3/58074 to 172.16.6.1/179 flags PSH ACK on interface SD-WAN-1
%ASA-7-710005: TCP request discarded from 172.16.6.3/58074 to SD-WAN-1:172.16.6.1/179
%ASA-6-106015: Deny TCP (no connection) from 172.16.6.3/58074 to 172.16.6.1/179 flags PSH ACK on interface SD-WAN-1
%ASA-7-710005: TCP request discarded from 172.16.6.3/58074 to SD-WAN-1:172.16.6.1/179
%ASA-6-106015: Deny TCP (no connection) from 172.16.6.3/58074 to 172.16.6.1/179 flags PSH ACK on interface SD-WAN-1
%ASA-7-710005: TCP request discarded from 172.16.6.3/58074 to SD-WAN-1:172.16.6.1/179
%ASA-6-106015: Deny TCP (no connection) from 172.16.6.3/58074 to 172.16.6.1/179 flags PSH ACK on interface SD-WAN-1
%ASA-7-710005: TCP request discarded from 172.16.6.3/58074 to SD-WAN-1:172.16.6.1/179
%ASA-6-106015: Deny TCP (no connection) from 172.16.6.3/58074 to 172.16.6.1/179 flags PSH ACK on interface SD-WAN-1
%ASA-7-710005: TCP request discarded from 172.16.6.3/58074 to SD-WAN-1:172.16.6.1/179
%ASA-6-106015: Deny TCP (no connection) from 172.16.6.3/58074 to 172.16.6.1/179 flags PSH ACK on interface SD-WAN-1
%ASA-7-710005: TCP request discarded from 172.16.6.3/58074 to SD-WAN-1:172.16.6.1/179
%ASA-7-609002: Teardown local-host identity:172.16.66.1 duration 0:02:01
%ASA-7-609002: Teardown local-host SERVICE-666:172.16.66.2 duration 0:02:01
%ASA-6-106015: Deny TCP (no connection) from 172.16.6.3/58074 to 172.16.6.1/179 flags PSH ACK on interface SD-WAN-1
%ASA-7-710005: TCP request discarded from 172.16.6.3/58074 to SD-WAN-1:172.16.6.1/179
%ASA-6-106015: Deny TCP (no connection) from 172.16.6.3/58074 to 172.16.6.1/179 flags FIN PSH ACK on interface SD-WAN-1
%ASA-7-710005: TCP request discarded from 172.16.6.3/58074 to SD-WAN-1:172.16.6.1/179
%ASA-7-609001: Built local-host SD-WAN-1:172.16.6.3
%ASA-6-302013: Built inbound TCP connection 23576 for SD-WAN-1:172.16.6.3/35858 (172.16.6.3/35858) to identity:172.16.6.1/179 (172.16.6.1/179)
%ASA-3-418018: neighbor 172.16.6.3 Up


Eventhough it is logged, the ACL hitcnt doesn't increase
fw01-tgl-cph(config)# show access-list
access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096)
alert-interval 300
access-list DENY-ALL; 3 elements; name hash: 0xfa20fecd
access-list DENY-ALL line 1 extended deny ip any any log informational interval 300 (hitcnt=0) 0x42b7c013
access-list DENY-ALL line 2 extended deny tcp any any log informational interval 300 (hitcnt=0) 0xba274680
access-list DENY-ALL line 3 extended deny icmp any any log informational interval 300 (hitcnt=0) 0xe4e3a9ec

I see you use FW HA do you see any fail over when you apply the ACL 
it can the standby be active and since the IP is flap (standby new active now use IP of old active) the standby new active form the bgp with Peer not the old active 
MHM 

Doesn't look like there is any failover when I play around with ACL.

Also wouldn't standby use the same IP to establish bgp regardless?

fw01-tgl-cph(config)# show clock
20:38:15.770 UTC Sat Dec 30 2023


fw01-tgl-cph(config)# show failover
Failover On
Failover unit Primary
Failover LAN Interface: FAILOVER Ethernet1/7 (up)
Reconnect timeout 0:00:00
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 5 seconds, holdtime 25 seconds
Interface Policy 1
Monitored Interfaces 5 of 1288 maximum
MAC Address Move Notification Interval not set
Version: Ours 9.16(2)3, Mate 9.16(2)3
Serial Number: Ours JAD272506Y1, Mate JAD272109R9
Last Failover at: 09:43:17 UTC Dec 22 2023
This host: Primary - Active
Active time: 733708 (sec)

Marvin Rhoads
Hall of Fame
Hall of Fame

Like @MHM Cisco World said. You could also clear the conn for just the peer addresses listed.

Also, the second Access-group command is for traffic THROUGH the firewall and thus not needed. You only need the control-plane ACL for traffic TO it.

Yeah I know, I just added it just in case it would work. ACL do work for transit traffic through the device but not to the device itself.

I did try to clear bgp connection but it says 0 connections eventhough there are 2 established essions

# clear conn protocol tcp port 179
0 connection(s) deleted.

 

# show bgp summary

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.16.6.3 4 666 105 86 3 0 0 01:32:27 0
172.16.7.3 4 666 345 283 3 0 0 05:11:15 0

TCP SD-WAN-1: 172.16.6.3/14740 (172.16.6.3/14740) NP Identity Ifc: 172.16.6.1/179 (172.16.6.1/179), flags UOB , idle 8s, uptime 1h1m, timeout 1h0m, bytes 1233
Initiator: 172.16.6.3, Responder: 172.16.6.1

220136-build-up-and-teardown-asa-tcp-connection-01.jpg

that is pretty cool and I will save that image. But still from my point of view, the Three-way handshake (U) should never be completed. Or am I missing something from that information.

Yes, you are correct, 
the TCP handshake never be  complete but it complete U 
why I sharing this because the Inbound and Outbound data 
as I see from what you share there is Only "O" meaning only Outbound 
there is no Inbound.
also the control-plane ACL is override by the HTTP/SSH/Telnet apply the interface for mgmt. 
MHM

I am a bit confused now whether this is the expected behavior? As I understand there shouldn't be any outbound from the ASA(passive) for BGP, because technically it should not receive anything from Remote to begin with since it would be dropped by ACL.

Review Cisco Networking for a $25 gift card