Route Tagging OSPF Fortigates

In this post we will look at a simple deployments for tagging OSPF routes.


Why you would tag routes depends on a few things, but typically this is done for advance routing selection and manipulation. This gives you a greater luxury with route selection and controls.

E.G

>You might have 2  ISP uplink providers & both injecting a "External default route ", but you  request a unique ospf  tag for each default route to allow for routers/firewall to select the default  route by using the ospf tagged value

Or 

> you need to filter a set of routes from one router advertisements over another, like in a development network or in a redundant DataCenter recovery.


In this example we will tag our default route that we inject, and a few /24s prefixes

The tag I have chosen for the default and  the non-Default routes have  no bearing on the value selected. Typically one crafts a tag-value policy for routes redistributed by location and/or export method.

Here's an example of an route-tage policy for routes published for a router;

Here's our cfgs;

I've built 2 named prefix-list to match default and our  10.200.11.0/24 network

The route-map matches our prefix, &  will set the tag value  that we will set 

In our router cfg, we apply the route-map to the default and under the export section  for the route-distributions. It's named redist-def .

 

Finally we can check our ospfdatabase for the correct tag-value

  I used a value 289 for the general set tag-value for redistributed
statics. 

The route-map named  will match and apply 1st &  before any set tag values under each section. So if you apply a general set tag value + route-map, the rt-map rules will be evaluated 1st.

If I should have removed route-map named "ospfagover" than all static routes would have the value=289 applied. If no value was set, than the route-tag value in the LSA would be null


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

    ^     ^
=(  :    : )=
        o 
       /   \

FortClient 5.2.3

I just finished changing a few macs and one window machine to run the latest 5.2.3 build from fortinet over this last week. It seems to run very good and the  performance with SSLVPN  has improved.

I did run into a installer issue ( windows 7 home ) looping thru the download and package install process. I had to erase the install and try again. To bad fortinet doesn't allow you to download the image directly.

www.forticlient.com/

 

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

    ^     ^
=(@)  (@)=
        o 
      /   \

renaming a kvm image after it's been installed

I needed to rename a  KVM vm-image and qcow2 name file. So here what I did. This quick steps can be done in less than 5mins depending if you copy the  original images or make backups.

1:  You need to shutdown the vm image in  question

virsh shutdown vmimageoldname

 Ensure it's shutdown before continuing




2A:  Now copy the actual qcow2 image file to a safe spot ( optional )

cp vm-mai.qcow2  ~kfelix/mybackup.qcow2

2B: Copy or rename the  original qcow2 image to it's new

cp vm-oldimagename.qcow2  vm-newimagename.qcow2 


3: Run the unix  md5sum on original and copy

md5sum  oldimage  newimage

4: The dump the  xml data for the oldimage

virsh dumpxml old_named > ~kfelix/myold.xml ( as seen from virsh list -all )

Now here's what it get's to be fun, you create a copy of the xml file  and undefine the old

5: cp  ~kfelix/myold.xml ~kfelix/mynew.xml

6:  You also need to undefine the old image virsh undefine old_named

7: edit the new xml ( make all changes and double check the changes name/description/uuid/image type )

8: You can now define the image using the newly crafted and edit xml file  virsh define ~kfelix/new_named.xml

9: And now finally  start the new_named image

 virsh start  newimage_name

If you try to undefine a vm with snapshots you will get this error messages. Delete all snapshots before deletion of the old image

 tip if you want to keep the old kvm vmimage around for awhile, and do not want to undefine or delete, make sure to mark it's autostart  state as disable  virsh autostart --disable vm-oldname

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

    ^     ^
=(  @  0 )=
        o 
      /   \

ipv6 traceroutes that don't report next-hops correctly from sit-tunnels fortigate

I will show you why a ipv6 traceroute  across Hurricane Electric ( HE ) or almost any other  ipv6 tunnel will always fail when using a fortigate firewall appliance or perform poorly.

  
It's very sad to say the least & I was shock to say the least when I identified the issue, FTNT flunked big time grade =  F minus !

 
But 1st here's a cisco traceroute  and a sample ipv6 debug output to show what we are expecting in our fortigate ipv6 traceroute

Our tunnel details as provided by HE.net are quite simple and easy to configure.

So first we create a  ipv6 tunnel on  our macosx-laptop using the example cfg that HE provides and conducts a simple  ipv6 traceroute and packet capture so we can see what's missing from our fortigate ipv6 traceroute.

I did this to build comparative data and macosx kernel has great support for ipv6 as most bsd flavored OSes


Here's a sample ipv6 tunnel cfg used in our testing.

BTW the HE tunnelbroker will generate various sample configurations based on  your end-device. HE tunnelbroker by far is one of the simplest broker to use, if not the best.


( x.x.x.x would be you  public facing interface that SRCs the ipv4 tunnel packets )

ifconfig gif0 create
ifconfig gif0 tunnel x.x.x.x 216.66.84.42
ifconfig gif0 inet6 2001:470:1f12:3d::2 2001:470:1f12:3d::1 prefixlen 128
route -n add -inet6 default 2001:470:1f12:3d::1

Yeap it's really that easy ;)

Now I will show why certain ipv6 traceroute will gain a response. It has to do with the protocol used in the traceroute ( ICMP vrs UDP )

A UDP traceroute6 from my macosx shows the following;

A ICMP traceroute6 from my macosx shows the following;

As you can clearly see, both style of traceroutes works for ipv6 ( UDP | ICMPv6 )  & the  HE ipv6 gateways in the route path responds as expected. This is all good and what's expected.

The fortigate defaults with-only using ICMP  with both ipv4 or ipv6 generated traceroutes. You can confirm by executing a diag sniffer packet <interfacename>  "target-destination-address". This is bad if a ipv6 next-hop gateway is set to filter or rate limit ICMPv6 packets.

So I open a ticket with HE just to see what respond they would provide on lack of responses from the traceroute6 requests, and they at first gave me a single one liner response with no other explanation when asked if they filter ICMPv6.

In my 18+ years of using ipv6, most traceroute6 tools/utilities, has the means for toggling UDP and ICMP within the traceroute6 cmd selection upon execution but not a Fortigate.

Here's a snippet of my macosx 10.10 manpage;

But, why does the MACOSX gif tunnel and ipv6-traceroutes using  ICMPv6 or even UDP works? 

and 

Why, a FortiGate ipv6-tracert using ICMPv6 does not respond, but a Cisco, SRX, Linux all works ?    ( That's the million dollar question,   so let's dive in and see why)

So I took a pcap of a traceroute using  a fortigate to see what's the issue could be & immediately seen the issue as to why a ipv6 traceroute over my SIT tunnel interfaces where failing  & until you reached a ttl of 10 or more.

1st, the ipv4 header TTL is mirrored to the IPv6  value hlim ( the name for ttl in ipv6----Next Hop Limit )

See the blue and green circle from this packet dump for comparing the ipv4 ttl value and mapped ipv6 hlim value....they match!

So no way will a ipv6 traceroute ever work,  since the ipv4 packet is dying enroute to the tunnel-server ipv4 gateway  which happens to be 216.66.84.42  { tserv1.par1.he.net  }.


So let's look at this again but from the ipv4 stand point. If I traceroute from the fortigate directly to the ipv4  address where my tunnel terminates, "  how many hops would that take? "  let's find out;

Yeap 11 hops to tserv1.par1.he.net { 216.66.84.42 }

Now let's look at this again, the  ipv6 hlim is mirrored to the outer tunnel ipv4 header ttl value, and the ttl starts at 1 for this outer value.

So the traceoutes that we are conducting via ipv6 utility on a fortigate will never get to the intended target until the outer ipv4 packet get's to our tunnel termination destination.

Here's a ipv6 traceroute to a Japan DNS ipv6-server that will reflect this. We don't get our 1st ipv6 response until we hit  the 11th hop , which so happens to be when the outer ipv4 packet arrives at the HE tunnel-server

btw the above tracert6 was executed on a FGT110C running  4.3.x , I confirmed the same behavior on 5.0.x and have no done any 5.2 stuff yet

So bottomline, your 1st ipv6 response will be determine by how many  hops your away from  the ipv4 tunnel server.


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

    ^     ^
=(  :    : )=
        o 
       /   \

OSPF E2 route filter Fortigate

How to filter OSPF typeE2 routes using a  distribution list on  FortiGate. Some times you need to filter OSPF routes inbound & that you received from a OSPF neighbor.

In this example, I'm receiving the following ospf routes;

We will filter the last ospf type-E2 route 10.212.134.0/24.

Here's the basic steps;

1: 1st create prefix-list with deny action for the prefix(es) that you want to filter

2:  include a last match of any with an accept

3: apply the distribution list in the general ospf cfg

Now here's the cfg;

config router prefix-list     edit "dropit"             config rule                 edit 1                     set action deny                     set prefix 10.212.134.0 255.255.255.0                     unset ge                     unset le                 next                 edit 2                     set prefix 0.0.0.0 0.0.0.0                     unset ge                     set le 32                 next             end     next end
Ensure you have a any any cause to allow for all others,  insert any new filter rules with the exact match or criteria as required

Now build the distribution map in our general ospf configuration;

config router ospf 
   set distribute-list-in "dropit"
   end

Keep in mind the ospf LSA database will always shows the  LSA for this network regardless if it's filter from RIB.

A distribution list is not the most ideal way of controlling route migrations, you should always control route dissemination at the source of the routing info imho.





And here's our ospf route infromation after we apply the filtering;

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

    ^     ^
=(  !  ! )=
       o 
      /  \

sslvpn ssl.root management access

A client of mine,  had a specific security requirement for allowing remote management of a fortigate via SSLvpn remote access.


E.g of the network topology top view. Each remote nets are objects in the untrusted cloud space

Now the government agency they are working with wanted the following;

1: no direct ssh access
2: no direct telnet access ( that should be obvious but .....just in case )
3: no direct HTTP or HTTPs access ( the former protocol should be obvious to a security engineer as weak )
4: no ipsec vpn
5: A person must go thru a vpn to access the fortigate & by using ssl encryption


Now items #1,2,3 was simple we did not allowaccess ssh http https or telnet on our outside untrusted interface,  but item #5 caused a wake of numerous  round table discussions.

And knowing the gov, they wanted to install  a 30K solution with yet another appliance for vpn access & controls just for gaining access to a dozen or so fortigate appliances.

BTW, they needed  SSL access vrs IPSEC, due to a lot of foreign networks have a high degree of not allowing ipsec traffic to flow.


So I crafted a POC  & that I'm proud to say they bought after  careful  review.

Here's what I did;

1: I built a vpn group and assigned it a unique ipv4 pool that we also set into our trusthost

2: we assigned a ipv4 address to the ssl.root interface ( yeap it's a interface like any other interface , in fact it's a tunnel interface hence the /32 mask )

3: Next we allowed the approved access management ( ssh ) over this sslvpn

Now I want to point out the following;

>  This method is a little overkill for security , since we have ssh encryption encrypted into another encryption type ( SSL )

>  Also if any  sec-engineer screws up any sslvpn settings, they could disable the access

>   Also in our case the remote vpn was authenticated via radius, so the user needs to have 1> a radius access account 2> and the local system administration account

Once again .......overkill, but  than the average government wants overkill!

Now with strong crypto ciphers in the webvpn  portal, you can now protect a weaker access that might be vulnerable ( SSH )

Do you recall the past debian OpenSSH keys issues ?




Here's the ssl.root cfg

And just create a ssl vpns setting and a portal that has tunnel-mode and assign the group.


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

    ^     ^
=(  *  * )=
        o 
       /  \

Uperf for sctp benchmark

The folks at uperf org has a testing tool that allows for you to build a  sctp benchmark  profile for testing  sctp thru-put. It's also great if you want to generated SCTP traffic to throw over a firewall interfaces .  https://twitter.com/uperf

The SCTP ( stream control transmission protocol ) is  yet another  layer4  transmission protocol.

To run this on 2 hosts you set one host up as a slave and the other as the master.

e.g

You will need to install the sctp libs

e.g

apt-get install libsctp-dev

And acquire the source for compiling;

wget http://sourceforge.net/projects/uperf/files/uperf/uperf-1.0.4.tar.bz2


Conduct your simple configure and make install and you then should have a working uperf utility.

Here's a simple SCTP session;


CLIENT SCTP 82 INIT
SERVER SCTP 306 INIT_ACK
 
CLIENT SCTP 278 COOKIE_ECHO
SERVER SCTP 50 COOKIE_ACK
 
CLIENT SCTP 318 DATA
SERVER SCTP 62 SACK
 
CLIENT SCTP 60 SHUTDOWN
SERVER SCTP 50 SHUTDOWN_ACK
CLIENT SCTP 60 SHUTDOWN_COMPLETE 


Now for testing you will need to define a profile and ensure you  active the profile for the test in hand. Here's a very simple and basic tcp profile for testing;

<?xml version="1.0"?>
<profile name="TCP-test01">
        <group nthreads="$t">
                <transaction iterations="1">
                     <flowop type="connect" options="remotehost=$h protocol=$p"/>
                </transaction>
                <transaction duration="60s">
                     <flowop type="read" options="size=64"/>
                     <flowop type="write" options="size=64"/>
                </transaction>
                <transaction iterations="1">
                     <flowop type="disconnect" />
                </transaction>
        </group>
</profile>

You will need to populate the variable listed above during the test

<?xml version="1.0"?>
<profile name="SCTP">
  <group nthreads="1">
        <transaction iterations="1">
            <flowop type="connect" options="remotehost=$h protocol=sctp" />
            <flowop type="write" options="count=2 size=64"/>
            <flowop type="disconnect" />
        </transaction>
  </group>
</profile>

To use the above we would  do  the following.

( master)

export h=127.0.0.1 ; uperf -m sctp1.xml -v


(slave )

uperf -s


Here's a few sample output ;

If you compile ssl support with the correct libs you can measure pure ssl performance.






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

    ^     ^
=(  *  * )=
        o 
       /  \

DNS sandbox ipv6

Here's an interesting ideal ;

https://www.opendns.com/about/press-releases/opendns-announces-ipv6-dns-sandbox-first-available-public-ipv6-recursive-dns-service/


This should eliminate any problems with the migrating  of DNS objects into  the ipv6 realm. A SandBox will allow for quick testing  before any migrations  & involving a productive networks.

The OpenDNS public ipv6  anycast address;

2620:0:ccc::2
2620:0:ccd::2

For more sandbox experience sandbox.dnsimple.com. They have both ipv4/6 dns service hosting that's simple to  deploy.

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

    ^     ^
=(  !   ! )=
        o 
       /  \

2620:0:ccc::2 2620:0:ccd::2

2620:0:ccc::2 2620:0:ccd::2

I thought this was really funny ( fortigate tac report no ipv6 route details )

I was working an issue with  ipv6 routing and had to generated a  tac report ( cli cmd  execute tac report ) and the output had no  ipv6 routes details.

Fortinet typically  does good with most of the features pertaining to ipv6 , but they totally struck out on this one.

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

    ^     ^
=(  *  * )=
        o 
       /  \

JunOS 12.3x48 rls is out

I'm in the process of downloading and reviewing the rls notes for this firmware.

And the only new feature that seemed of interest to me was  VRRPv3 and Ipv6 transparent mode. The latter will be quite interesting to see what and how a SRX mid-range platform works

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

    ^     ^
=(  *  * )=
        o 
       /  \

Playing the IOS "shell" game

Cisco IOS has started to provide  a limit  shell like functions with in the IOS code.  This allows you to use  simple unix shell commands suchs as;  wc, grep, more, tail, sleep,etc....


Here's a few example, but 1st you have to  execute the shell process via your terminal command

e.g

terminal shell

 

How about setting a variable

A simple word count of our config file

More examples;

 

You have a host of options for deploying the IOS shell in your scripts or day to day uses.





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

    ^     ^
=(  *  * )=
        o 
       /  \