A quick look at MACOSX GNS3 and junos

NOTE:Please don't email me for a junos image 

In this post, we will look at installing a prep  junos image into GNS3 and seeing how simple it can be. The version of  MACOSX &  GNS3 I'm running ;

Now to install the image, you only need to  craft your junos configuration GNS3
preferences  Qemu > JunOS

And after you have the image installed, you can boot the image and have at it.


Once GNS3 boots up the image,  username = root password = ( no password )

and here's your login prompt

Login =  root ( no password )

Once you have gained access, just type  the cmd  "cli" to get a prompt, and then "configure" and you can start configurations.

note: be patience, the images typically are large and can take any where from 2-10mins to fully boot.


GNS3 is great in  booting really images and testing  commands and features. It allows for a candidate to get experience & without buy expensive hardware.


NOTE:Please don't email me for a junos image  

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(  @   @ )=

          o

       /     \

VPN ikev2 Juniper to Fortigate ROUTE_VPN ( parte2 )

In part1, we looked at the Juniper SRX and in this part we will explore the  Fortigate side of thing in regards to configurating a site2site vpn.

http://socpuppet.blogspot.com/2013/09/vpn-ikev2-juniper-to-fortigate-routevpn.html

The fortigate series like the juniper, also supports routed & policy based vpns. And to repeat; "a routed based vpn, has a route .....duh " :)

So 1st off let's look at the based of the configuration;

I flagged some parts of the configuration.


1st we are issuing a single proposal AES128/SHA1 that matches the proposal that was used on the Juniper. The reason for a single proposals; " we don't need to offer multiple proposal in a static L2Lvpn ( aka site2site vpn ) when we have 2 consenting  vpn devices.

By being deterministic and apply the  proper cipher and authentication methods for your VPNs, you eliminate possible issues.


It blows my mine when I see firewall engineers offering like  1+ proposals in a site2site VPN solution. Unless the vpn is for a dynamic client,   & where the  "clients" are possible unknown, we should defined exactly the proposal we should expect from our peer.

Next, the typical default offering of the proxy-id ( quick mode selectors ),  are to deploy the quick and easy  "0.0.0.0/0 proto 0" ,  but I never do that in a routed based vpn, even when doing this to another fortigate.

That's being lazy and in some firewall appliances  ( cisco, openswan, checkpoint,etc.....) that would cause problems later on.  Define the "exact" subnets for the local and remote networks between the peers.

And finally, the above solution needs a route installed and pointed at the named phase1 gateway. IN my case, I named it simply "SRX".

 And lastly ( not shown ) you need a fwpolicy to allow traffic to & from the vpn tunnel interface.

Yeap,

That's all that you need for a site2site vpn between a SRX to Fortigate. In this setup we are using IKEv2 which offers a few additional benefits over version1. One other key critical part that should be mention for IKEv2;  "during negotiation, only one DH-group should be installed "

As I stated above, "install one proposal, and only one proposal", save yourself the frustration.


Advantages in IKEv2;

•  It's quicker in setup (less messages  overall )
•  Can support unique authentication  parameters  ( different PSKs  for both local & remote and even intermingle PSK with Certificate  is supported )
• No more confusion as to if I need  "aggressive or main mode"
• both Juniper & Fortinet has support IKEv2 for the longest ( cisco just recently add support around ASA8.4 and the IOS routers have had it supported way before the ASA )

In part#3, we will look at some diagnostic steps and commands between the 2 chassis ( SRX and Fortigate FGT )

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(  @   @ )=

          o

       /     \

BGP table received only (demonstration)

A  junior  engineer asked me one day, a question about paths in the BGP table, & those marked received-only and why? 


In this example, I will try to demo just this action. But let’s look at a common bgp configuration that influence this.                                     

 "Soft-reconfiguration inbound "

This command is used by so many, but yet most don’t know the impact. When this command is applied to a  bgp neighbor, the  router must apply a copy of the bgp path b4,  and after any local policies are applied.

This will cause extra consumption of memory/cpu, due to the BGP path is stored in memoryfor both  pre & post bgp importing.

That this bgp cmd that will show you the original bgp path information per neighbor;

show bgp neighbors 134.22.12.22  received ?

  prefix-filter  Display the prefixlist filter

  routes         Display routes from this neighbor before inbound policy

Notice that command shows the BGP paths learned b4 your bgp import policy? Yes, we can see the path b4 you apply any route-policies against any prefixes.

Take this topology;

Okay R2 will be sending prefixes to R1 who has soft reconfiguration inbound applied. Also R2  has deploy bgp policies via  route-map.

R2 config

R1  bgp configuration applies a route-map  to manipulate BGP information "inbound".

Okay good so far, let's bring up the  BGP session and see what R1 does?

Okay, you see path #2 and the (received-only)? That's our BGP path B4 our local router manipulated the  BGP attributes. 

Clear ?

With out changing anything on R2, we will now take away the R1 soft reconfiguration inbound away and clear the session.

What do you think is going to happen with R1 BGP table , & after the bgp session has re-established?

Will let's see;

Okay you notice how the  (received-only) is gone? And we have just one BGP path in our table !

So with any neighbors or neighbors groups that have soft reconfiguration inbound, the local router has to maintain the "original"  path b4 our bgp importation and any path manipulations.

The opposite of this, is our "route-refresh" and if you remember a quite few post back, this capability is advertised during the BGP open and the  receiving router can always ask it's peer for a route-fresh.

Almost  ALL bgp speakers support route-refreshes. So unless you enable soft-reconfiguration inbound, you can ask even direct peer for a refresh. Be advise, if you don't have "soft reconfiguration inbound" set, you can clear the bgp peer without the risk of  dropping the neighborship;

e.g

Now let's look at memory consumption, so let's take a peek B4 soft reconfiguration is reapplied;

Okay nice, we have  3 network entries using 303bytes of memory for a total of 615 bytes of memory. So what happens after we re-apply the configuration?

and now we have;

I highlighted a few items and the main one is at the middle, we have 6 paths ( 6x received-only for the 3 prefixes ) and that the memory is now double. So picture a full-bgp-table and 400K+ prefixes and if you had soft-reconfiguration-inbound set. You now have the possibility to waste a lot of memory.

I hope you found this post useful and have a better understanding of what that command does and how it effects the bgp table and neighbors.

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(  @   @ )=

          o

       /     \

SSLVPN forticlient ipv6

In this blog, we will look at my  attempt with ipv6 assignments and with fortinet's fortigate/forticlient.

1st

I had serious challenges with getting the client to accept a ipv6 address. Fortinet TAC was called in for support and struggle with assisting me. So far , we are isolating if the problem is; " the  fortigate or the forticlient ".


Here's the  vpn ssl configs;

and;

And here's the static routes and address6 details;

Now originally when connecting,  I was only getting a ipv4 address. The FWF60D was NOT  reflecting this in the diag show commands btw;

e.g

So in our webUI, the  ssl monitor showed the following;

So at this point it was confusing as to what/why the client was not seeing any ipv6 assignments. Fortinet KB was also not of any help. So TAC was called in.

The logs didn't give any clue as to any errors or issues;

Stay tuned, we see what TAC proposes and so far I was not impressed with the TAC. They where trying to proposed that I can't assign a ipv4 and ipv6 address at the same. The fortigate actually kicks a error if you  remove the ipv4-pool and enable a ipv6-pool-only.


I will keep you posted on any developments on this front.

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(  @   @ )=

          o

       /     \

Identification of interface Index IOS-XR 4.2.3

How to find the  SNMP ifIndex IDs on a  ASR9K IOS-XR.

Most network devices has some type of SNMP interface index numbers. In cisco and like most other devices, normally the ordering of the interface matches the ifindex number & for hard interfaces;

e.g

show ip int br

Interface              IP-Address      OK? Method Status                Protocol

GigabitEthernet0/1     unassigned      YES unset  down                  down   

GigabitEthernet0/2     unassigned      YES unset  up                    up      

GigabitEthernet0/3     unassigned      YES unset  down                  down   

GigabitEthernet0/4     unassigned      YES unset  down                  down   

GigabitEthernet0/5     unassigned      YES unset  up                    up     

GigabitEthernet0/6     unassigned      YES unset  down                  down   

GigabitEthernet0/7     unassigned      YES unset  down                  down   

GigabitEthernet0/8     unassigned      YES unset  down                  down   

GigabitEthernet0/9     unassigned      YES unset  down                  down   

GigabitEthernet0/10    unassigned      YES unset  up                    up     

GigabitEthernet0/11    unassigned      YES unset  up                    up     

GigabitEthernet0/12    unassigned      YES unset  up                    up     

GigabitEthernet0/13    unassigned      YES

( output truncated )

So gi0/1 would be ifIndex.1

     gi0/2 would be ifIndex.2

     gi0/3 would be ifIndex.3

     gi0/4 would be ifIndex.4

     gi0/5 would be ifIndex.5

and so on

After the real hard interfaces, any virtual interfaces would start at the next available number. Virtual interfaces would be vlan-SVI,tunnels, Null0, bridge-group-interfaces, loopbacks, etc……

You can use any of the following means to find the ifIndex numbers on IOS-XR to find the interface index numbers.

Method#1

(cmdline )

show snmp  interface gigabitEthernet 0/0/0/2 ifindex

Thu Sep  1 11:30:22.959 UTC

ifName : GigabitEthernet0/0/0/2  ifIndex : 445

Method#2

It requires that you enable ifindex persistence first;

config t

  snmp ifindex persist

commit

This does 2 things;

• ·      It craft’s a persistence within the ifIndex  ( so if you add/remove a interface card or virtual-interfaces nothing changes )
• 
  
• ·      And this information is stored on the file-system disk and read by the OS

You can dir & more this file via the commands;

dir disk0:snmp/

and

more disk0:snmp/ifindex-table

NOTE: this is unix, so case sensitive is a must

Now why would we want to know the ifIndex #?

Simple, in monitoring, graphing and querying  interfaces, the known  ifIndex # can be very helpful. 

e.g

Great if you want to ensure that ifIndex.1 is really gi0/1 and not on tunnel 777.

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(  @   @ )=

          o

       /     \

VPN ikev2 Juniper to Fortigate ROUTE_VPN ( part#1 )

In this post we will look at a simple   VPN between a Fortigate running a 5.0.3 and Juniper running 12.1X44-D20.3

Here's the topology;

We will allow for all traffic between the 10.10.80.0/24 ( FGT ) to 10.98.10.0/24 ( SRX ). The models of gear involved;

Fortigate FWF60D
Juniper   SRX210H

1st, I want to upgrade my  Juniper to the following codeset.

After the upgrade and reboot, we start the the configuration.

Now let's begin;


 Let's define some proposal and policies;

Okay simple we are allowing for  AES128-256+sha1 and a ikepolicy "ike1" with PSK, using main mode. Now we bind the  policy to the  gateway entry. I called my gateway  fgtfwf60d.

NOTE: since we are doing  ikev2 we specify v2-only.

here's the cfg lines;

set security ike proposal ike-p1  authentication-method pre-shared-keys

set security ike proposal ike-p1  dh-group group5

set security ike proposal ike-p1  authentication-algorithm sha1

set security ike proposal ike-p1  encryption-algorithm aes-128-cbc

# 

set security ike policy ike1 proposals ike-p1

set security ike policy ike1 pre-shared-key ascii-text S3cur3d1ty

#

#

set security ike gateway fgt-wf60d external-interface ge-0/0/0.0

set security ike gateway fgtfwf60d ike-policy ike1

set security ike gateway fgtfwf60d address 100.100.100.1

set security ike gateway fgtfwf60d version v2-only

Okay now lets create a tunnel interface. keep in mind this is a route-base VPN, so that means we have a "route" to get to the remote network or we using a routing protocol over the vpn. The alternative, is a "policy" based vpn. And that means just that, we deploy a firewall policy.

And the corresponding configurations;

set interfaces st0.0 unit family inet 

set security zones security-zone untrust-ipsec interfaces st0.0

set routing-options static  route 10.10.80.0/24 next-hop st0.0

I want to stop and explain the config up to  this point;

1. we've defined our IKE proposal & policies
2. we've bound these to a gateway named fgtfwf60d
3. we crafted a virtual interface named   st0 and applied it in a  security zone 
4. we have a "routed" install to reach the right-subnet

So the last part; we must have fwpolicies to allow traffic from the local to remote networks.

So here's the final configurations;

set security zones security-zone remotevpn01 interfaces st0.0

set security zones security-zone remotevpn01 address-book address REM01 10.10.80.0/24

set security zones security-zone trust address-book address LAN01 10.98.10.0/24

fwpolicy

It's a good ideal to tcp-adjust ipsec traffic aka mss-clamping.

set security flow tcp-mss ipsec-vpn  mss 1360


Ipsec will have some over head, so the  overall tcp traffic mss value needs to be reduce for this overhead.

( stay tuned, we look at the  FGT side of things next  in part 2 )

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(  @   @ )=

          o

       /     \