Updating TACACs on an older Wildpackets Omnipliance

I had to update the TACACs server details on an old OmniPliance which proved to be quite confusing. I found the location of the settings but each time we restarted the service it reverted back to the way it was.

Quite a simple solution in the end… The procedure is below.

$ ssh root@omnipliance1
# service omnid stop
# vi /etc/omni/engineconfig.xml

Edit the following line in engineconfig.xml


Quit with :wq! and restart the service.

# service omnid start

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. :)


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 ];

Using the Cisco 3650 Managment Port

Configuring some new Cisco 3650s, I wanted to use the management ports rather than setting up management LAN SVIs and so on. This is particularly useful in a DMZ as we know the management port is in a completely different VRF.

Here’s a short summary of the steps taken to get around things not working at first as the traffic wasn’t being source from within the management VRF. IP addresses are only for the purposes of examples.

First off, configure the management interface and default route:

interface GigabitEthernet0/0
 description ** Network Managment Interface **
 vrf forwarding Mgmt-vrf
 ip address

ip route vrf Mgmt-vrf


logging source-interface GigabitEthernet0/0 vrf Mgmt-vrf
logging host


ntp server vrf Mgmt-vrf


ip tftp source-interface GigabitEthernet0/0

AAA needs a modification to work

aaa group server tacacs+ TACACS_GROUP
 ip vrf forwarding Mgmt-vrf

ip tacacs source-interface GigabitEthernet0/0


snmp-server host vrf Mgmt-vrf version 2c YOURSTRING

That covers the essentials!