VLAN cisco reservation internal usage ( thoughts )

With Vlan IDs  we have some that we  should be avoid & this issue bound to come up in big networks with hundreds if not thousands of vlans.

The following show command  under IOS/NX-OS will display these internal usage vlans;

e.g

show vlan internal  usage

If you try to configure a vlan that's used internally, you will have an error similar to the  below.

Now luck has it that cisco has created a means for reserving  vlans. It's sometime best to apply this practices in big SP/ENTERPRISE networks to avoid design issues  that could later conflicts with a reserved vlan.

Our socpuppets general thought has always been to craft vlans under the 4K range,  and build a vlan allocation sheet that you SHOULD always review b4 vlan allocations.

The "vlan internal  allocation policy ascending" or "vlan internal  allocation policy descending" commands can help in determining the internal vlan allocation methods.

NOTE: I believe this is a IOS command and not widely deploy under most  NX-OS switches.

Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \

NX-OS howto md5 check 3500s

On a nexus 3524 you can use the following means for file md5sum checking & file-image integrity. The size of the file will determine how long it takes to complete the md5sum verification.


show bootflash:<filename>  md5sum

E.g

NOTE : The NX-OS will also perform a image verification when setting the boot var

E.g

or you can execute the following;

E.g

Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \

SIP registering issues cisco ASA

In this blog we will look at a sip UA client ( X-lite ) and using the call centric services. One of the biggest problems with  SIP clients soft or hardware based ,  involves with the SIP  registrations.

A few reasons that can cause a SIP REGISTRATION or failures

•  bad sip domain specified at the client
•  username incorrect ( SIP register name = Sip.To ) 
•  bad  sip account password
•  the firewall filtering your protocol and ports ( TCP|UDP port5060/5061 )
•  ALG not enabled  nor fixing up the SIP header
• lack of re-REGISTERs or lack of SIP-KeepAlives
• severe packet lost preventing registering ( not common but could happen )
• you have trip the max registers per client or some Admission controls thresholds ( usually this is set at the SIP provider server/proxy )

Here's a SIP-register from my X-lite client on my MACOSX client

Now the firewall plays an important process. It must fixup the SIP REGISTER and mask the  SESSION details to match your public SNAT address if NAT is enabled between the UAC and UAS.

Obviously you must have firewall policies that allows the traffic outbound from your client to the sip server to begin with.

NOTE:  With the call centric the protocol for registering is done via SIP using defector udp/5080. Some clients will revert to TCP and even to ports 5060 |5061 as an alternative but you need to double each client and what the SIP provider is expecting. In my  X-lite and Callentric  they use 5080 which is typically the default for Sip clients that uses proxy-registration  versus a sip trunk Carrier which hardly uses SIP-REGISTERs.


For "Bad" authentication , is actually easy to determine if this has happen by monitoring  the SIP status-codes between client and server.

1   9.698676 10.200.41.89 -> 204.11.192.22 SIP 610 Request: REGISTER sip:callcentric.com  (1 binding) | 

  2   9.941065 204.11.192.22 -> 10.200.41.89 SIP 553 Status: 407 Proxy Authentication Required | 

  3   9.942312 10.200.41.89 -> 204.11.192.22 SIP 811 Request: REGISTER sip:callcentric.com  (1 binding) | 

  4  10.186344 204.11.192.22 -> 10.200.41.89 SIP 386 Status: 403 Incorrect Authentication | 

  5  15.373261 10.200.41.89 -> 204.11.192.22 SIP 610 Request: REGISTER sip:callcentric.com  (1 binding) | 

  6  15.633247 204.11.192.22 -> 10.200.41.89 SIP 553 Status: 407 Proxy Authentication Required | 

  7  15.635155 10.200.41.89 -> 204.11.192.22 SIP 811 Request: REGISTER sip:callcentric.com  (1 binding) | 

  8  15.883003 204.11.192.22 -> 10.200.41.89 SIP 386 Status: 403 Incorrect Authentication | 

  9  27.379048 10.200.41.89 -> 204.11.192.22 SIP 610 Request: REGISTER sip:callcentric.com  (1 binding) | 

 10  27.626802 204.11.192.22 -> 10.200.41.89 SIP 553 Status: 407 Proxy Authentication Required | 

 11  27.628884 10.200.41.89 -> 204.11.192.22 SIP 811 Request: REGISTER sip:callcentric.com  (1 binding) | 

 12  27.894571 204.11.192.22 -> 10.200.41.89 SIP 386 Status: 403 Incorrect Authentication | 

NOTE: It doesn't tell you what was wrong other than your authentication was incorrect. It could have been username,  password or both, remember the server & client are using a cryptographic nonce to ensure the password is hash to a value that can't be replayed. So if the domain is correct, just  rekey the username and password


Now with the cisco ASA, all we need to do is to ensure our  policy-map has sip inspection enabled and to ensure it's applied globally or on the interface.

Here's a typical ASA policy-map cfg;

policy-map global_policy

 class inspection_default

  inspect ftp 

  inspect h323 h225 

  inspect h323 ras 

  inspect ip-options 

  inspect netbios 

  inspect rsh 

  inspect rtsp 

  inspect skinny  

  inspect sqlnet 

  inspect sunrpc 

  inspect tftp 

  inspect xdmcp 

  inspect pptp 

  inspect ipsec-pass-thru 

  inspect icmp 

  inspect icmp error 

  inspect http 

  inspect snmp 

  inspect dns preset_dns_map 

  inspect sip  

 class internal_network

  inspect esmtp 

 class class-default

  inspect pptp 

  user-statistics accounting

You can use the following show commands to confirm inspect for SIP;

show service-policy inspect sip table

And for monitoring any flows

show conn protocol udp port 5060-5061 long

show conn protocol tcp port 5060-5061 long

or

show conn protocol udp port 5080 long

And you can monitor the expiration and refresh to get an ideal of how long your sessions are up and when they refresh, this should match the SIP keepalives intervals  for the UAC

UDP EXTERNAL02: 204.11.192.22/5080 (204.11.192.22/5080) TRUST01: 10.200.41.89/55589 (1.22.11.100/55589), flags - , idle 1s, uptime 8m18s, timeout 1m0s, bytes 17115

A few other items to think about, do you need 1> SIP re-REGISTER and  2>KEEPALIVES. The answer for this really depends.

But  SIP keepalives will ensure the firewall NAT/SESSION table stays active and does not expire from the  session list. It never hurts to enable a reason SIP session timer.  You can also get by with increase sessions timeout in the  cisco ASA for SIP for the session table

The show run timeout cmd will provide you an ideal for SIP sessions values

timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00

timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute

The choice is all yours on what you need to do, but be aware of the few listed issues that effects SIP registering  and how your Cisco ASA fits into the  picture.

Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \

tips "Fortigate logging for IPS attack events"

One of the biggest gotcha when using  the forties IPS sensor is the lack of logs  in the WebGUI. One easy mistake is forgetting to  enable logging for memory vrs foricloud

Next, you need to enable logging per IPS sensor event.

After your have done the above, you can now witness any Alerts within the log &report > security  from the main page.


Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \

Fortimail and cisco cables

In this post I will demostrate the usage of cisco cables SFP-H10GB-CU3M enlew of  SFPs for connecting a FML to a cisco 6509-E.

Most if not ALL Fortinet gear, is pretty much cisco compatible for ALL SFPs that I've used in the past.  You can pretty much use any standard  badged/labeled  cisco SFPs in fortunate gear and it will work.

Here's the  FML 3KD  configuration for the SFP slot interface in the back.

No on the switch I was surprised that cisco showed there own cables not compatible .

NOTE: I'm using the service unsupported transceiver commands on this switch btw.

service unsupported-transceiver

The  cisco gear works find and provides layer2 connectivity to the 3000D FML appliance

Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \

Digital Cloud Droplets in FRANKFURT has ipv6

I'm playing with ipv6 support & digitalcloud virtual machines. This will give me some time to try a few things over ipv6 and this cloud solution provider.

I'm running a basic  Debian host dual-stacked. I'm not even sure if you can request a ipv6-only stacked guest machines.

DigitalCloud has been a hosting provide for some time now and is a good  AWS alternative. They don't have a lot of dial and knobs but they are great if you need to plumb virtual guests and to simulate client machines for remote testing & if your on a budget.

It's typical to get a basic machine at $5-%7 dollars

https://cloud.digitalocean.com/


Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \

FortiOS 5.2.3 b670

v5.2.3,build0670,150318 (GA)

I did a few upgrades over the last week and now we are running  5.2.3 on all SMB fortigates. The upgrade went smooth & with a few big improvements notices off the get-go.

The slow feeling in the  webgui is pretty much gone.

Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \