Cisco ASA denying traffic between interfaces despite correct policy

After a bit of head-scratching and frustration, I found an issue on a Cisco ASA (v9.1) with the configuration that has caught me out twice previously. I felt like a bit of an idiot for not clicking sooner.

Basically the policy was allowing “icmp any any” both sides along with the connection traffic from the specific external to internal interfaces, however the logs were showing denials:

Inbound TCP connection denied from A.B.C.D/53112 to W.X.Y.Z/443 flags SYN  on interface Ext-2
Deny inbound icmp src Ext-2:A.B.C.D dst Ext-1:W.X.Y.Z (type 8, code 0)

The issue here was that both interfaces were configured with the same security-level. This is a hangover from the old PIX days where this kind of communication was denied by default. The policy doesn’t seem to matter.

The fix in this case was that the security-level on the “dirty” interface was lowered to a more appropriate value. To allow ACLs to control communications between same-level interfaces, the following command can be used:

same-security-traffic permit inter-interface

Juniper MX Port Numbering

Unfortunately the juniper port numbering scheme can cause a lot of confusion for people not familiar with the layout. This can get quite confusing when explaining to remote hands on site.

I made a quick reference which I use for some of our MX480s but the principle is the same on other hardware. This is handy for sending to third parties with a port highlighted to ensure they don’t go pulling the wrong cables. :)

juniper-ports

NNMi 9.24 Custom Poller Bus Adapter Errors

I was getting the following alerts regarding the custom poller on NNMi which was annoying users with the constant on/off status alerts.

“The Performance SPI Custom Poller Bus Adapter has status Critical because the average input queue duration…..”
“The CustomPoller Export Bus Adapter has status Minor because file space limit (2,000 MB) has been reached and older export data files are being removed to make room for new files.”

After some digging, it seems that the older files weren’t being deleted so this issue had actually crept up over time.

Apparently this was fixed by patch 5 but a workaround until then is to delete older files manually as follows. I strongly suggest running the find command without the “| xargs rm” part first to verify that you are indeed only finding regular files within the correct directory.

# cd /var/opt/OV/shared/nnm/databases/custompoller/export/final
# find . -mtime +365 -type f | xargs rm

Check the usage is under the size limit:

du -hs .
649M    .

Adding vlans to trunk on Juniper MX – behaviour

Just a small note on how the CLI on an MX behaves when you try to add vlans to an existing trunk as sometimes people are confused about doing this. Obviously it’s not really a problem as nothing happens until commit, but this works in a similar fashion to Cisco “switchport trunk allowed vlan-add xxx” command if you’re using set commands.

Existing config as below:

fe-0/0/3 {
    unit 0 {
        family bridge {
            interface-mode trunk;
            vlan-id-list [ 1 2 3 ];
        }
    }
}

Adding a vlan like this does not overwrite the existing config:

set interfaces fe-0/0/3 unit 0 family bridge vlan-id-list 5

Config is updated as below:

fe-0/0/3 {
    unit 0 {
        family bridge {
            interface-mode trunk;
            vlan-id-list [ 1 2 3 5 ];
        }
    }
}

iptables error: iptables: Setting chains to policy ACCEPT: security raw nat[FAILED]filter

I found that my VPN had stopped working on one of my linode hosted VPSs (CentOS release 6.5). I was struggling to suss this out but the logs suggested some sort of issue with network connectivity making TLS negotiation fail (“LS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)).

After a bit of head-scratching, I decided to restart iptables, only to be confronted with this error:

iptables: Setting chains to policy ACCEPT: security raw nat[FAILED]filter
iptables: Flushing firewall rules:                         [  OK  ]
iptables: Unloading modules:                               [  OK  ]
iptables: Applying firewall rules:                         [  OK  ]

That turned out to be the culprit and apparently this is a known issue.

Adding the following “security” section to /etc/init.d/iptables fixed the problem. Search for “Setting chains” (note the capital S) to get to the section you need. In my file I found this section at line 140.

    echo -n $"${IPTABLES}: Setting chains to policy $policy: "
    ret=0
    for i in $tables; do
        echo -n "$i "
        case "$i" in
+           security)
+               $IPTABLES -t filter -P INPUT $policy \
+               $IPTABLES -t filter -P OUTPUT $policy \
+               $IPTABLES -t filter -P FORWARD $policy \
+               || let ret+=1
+               ;;
            raw)