Pages

Monday, 14 July 2014

VPN between Netscreen and Checkpoint 1 kept failing from Checkpoint side

VPN between Netscreen ScreenOS and Checkpoint-1.

We have all been in the situation when a project, a Solution architect, a partner or customer wont listen to our recommendation to NOT mix products when setting up VPN.

In this situation it was a customer to my enterprise company that refused to accept us sending active equipment to be placed on their premises, and the customer of course did not want to put active equipment on our side. We strongly recommend to do either or, to have a clear, and more manageable demarcation point. And when i say demarcation point, i mean, sharing responsibility in the easiest way without any doubts of where the fault might be. Port-Cable-Port, within the same Rack if possible.

That left us with setting up an IPSEC tunnel over Internet between 2 different products, Checkpoint and Netscreen.

Checkpoint uses policy vpn, and Netscreen is more prune to Route based.

Im not debating on which Firewall/VPN Concentrator is the best etc, ill let others do that. But in general, most network companies dont follow the various RFC down to the spot. They all make some small adjustment as they find fitting for their need.

The problem we faced was that traffic initiated from the Checkpoint side when the VPN was down, didnt seem to bite, with that I mean it seems that the Phase1 from checkponit was not compatible what the Netscreen expected.

VPN would always go up if traffic was initiated from Netscreen to Checkpoint.

But since traffic was not always initiated from our side, we had a problem

Solution:
The solution was to enable monitor and rekey on the netscreen, ensuring VPN was re-negotiated without the need of traffic. We can still monitor the VPN by doing a simple IP-monitor on the other side.

In netscreen we have to use proxy-ids to match the Policy vpn configuration in Checkpoint, and ontop of that, have "monitor rekey" enabled.

set vpn "<vpn name>" monitor rekey

set vpn "<vpn name>" proxy-id local-ip 192.168.1.1&32 remote-ip 172.16.1.1&32 "ANY"


If you have any questions of the actual config, let me know.

Thursday, 10 July 2014

Helpful Dell Force 10 commands

When working with Dell Force 10 networking equpment. the following CLI commands is very helpful.

"show int status" - shows all interfaces and what vlans its member of. unfortunately it will not show which vlans its tagged and untagged in.

"show vlan" - shows your vlans, and what ports are member of those vlans.

"show vlt brief" - if you are using vlt lag portchannel, use this to show your status of your vlt's.

"q" - will exit the switch compared with HP-switches were you have to write "exit" to logout.

in config mode "int tengigbitethernet range <ports>" - with this you can set commands on multiple ports at the same time, like "switchport" or "spanning-tree"-options. instead of per interface.

Using tcpdump correctly in Linux

A common mistake made by engineers using tcpdump in linux is not reviewing the options. There is only so many times i had to correct engineers not able to grep specific ip-address from a tcpdump when reverse dns lookup is enabled.

As an example, if you use: "tcpdump -i eth0 | grep 172.16.1.1" and expect a response, but fail, please remove the pipe command and grep to see the raw data first. If you host has DNS configured, and that specific IP you trying to grep actually exists in the reverse-DNS, the tcpdump will post the dnsname instead of the ip. So always use the "-n" option to not resolve ips to DNS.

$tcpdump -i -n eth0 | grep <ip address>

If you want to avoid tcpdump to resolve known port number, add another "n"

$tcpdump -i -nn eth0 | grep <ip address>

for more option and more verbose you can add "-v" ir "-vv" or type "man tcpdump"

Force 10 % Error: Port is in Layer-2 mode Te-xx

Force 10 % Error: Port is in Layer-2 mode Te-xx

You probably get this message if you try to change mode of a a port that is already configured as switchport and spanning-tree edge-port.

The drawback with Dell Force 10 is that you have remove spanning tree and switchport before you can change portmode. then add back "switchport" and "spaning-tree edge-port"not sure why they did that.

interface TenGigabitEthernet 0/36
 description whatever
 no ip address
 mtu 12000
 switchport
 flowcontrol rx on tx off 
 spanning-tree rstp edge-port

so first
#no spanning-tree rstp edge-port
#no switchport
#portmode hybrid
#switchport
#spanning-tree rstp edge-port

Then it should show this.

interface TenGigabitEthernet 0/36
 description whatever
 no ip address
 mtu 12000
 portmode hybrid
 switchport
 flowcontrol rx on tx off 
 spanning-tree rstp edge-port

Voila, and you should be able to tag the port to a vlan, and have it untagged to another vlan.

Wednesday, 2 July 2014

Force 10 Network LLDP Neighbor Config

Force 10 Network LLDP Neighbor Config

If you are using lldp or Local Link Discovery Protocol in your Dell Force 10 Network deployment, enabling the ability to see the attached hostname by name when you punch "show lldp neighbor" would probably be very helpful in reference, especially when you are troubleshooting.

The command is:
#advertise management-tlv system-capabilities system-description system-name
and goes under interface/protocoll lldp. See below as an example.




interface fortyGigE 0/48
 description anything
 no ip address
 mtu 12000
 switchport
 flowcontrol rx on tx off 
!
 protocol lldp
  advertise management-tlv system-capabilities system-description system-name
  advertise interface-port-desc
 no shutdown

If you have any other question, message me.

/Silverfox