Archive

Posts Tagged ‘networking’

How to open a ticket with the FortiGuard team to request the creation (and testing) of a definition

June 10, 2013 Leave a comment

A while back, I came across the very cool piece of software called ScreenHero. It is a screen sharing + IM client that I’ve installed on several of my family members’ PCs and Macs. Unfortunately for my co-workers, I also wanted to block it through the use of the FortiGuard UTM services featured on our Fortigate firewall.

It is quite easy to request a new definition to be added.

Read more…

pim routing with a Fortigate

January 31, 2013 2 comments
There are some grammar errors contained herein. I also need to review a few things (related to DRs and RPs).
Here is a very valuable serverfault thread I’ve started with the conclusion that pim-dm should actually always be used, unless there is a need for low latency of packet arrival times 100% of the times.

Deciding on sparse mode or dense mode:

Dense: Consider this PASSIVE subscriber based (is given, asks for it to stop). It can be refered to as “push mode.”
When you are expecting to route multicast through few layer 3 devices. Dense mode uses a broadcast poller that fires a broadcast of “HEY WHO NEEDS THIS MULTICAST TRAFFIC?!” for which the other dense mode pim routers reply “I STILL HAVE CLIENTS! KEEP IT COMING!”

Sparse: Consider this ACTIVE subscriber based (isn’t given, asks for it). It can be refered to as “pull mode.”
When you are expecting to route multicast through many layer 3 devices to reduce the amount of traffic. Sparse mode is subscriber based, and fires requests up the tree (to a single router that keeps a database of all senders and receiving routers), multicast down the tree to ONLY _requesting_ routers.

Read more…

Sourcing a ping from a specific interface and address on a Fortigate

October 2, 2012 Leave a comment

The Fortigate ping function doesn’t allow you to specify a source interface, which is sort of annoying.

So instead, you have to source it from a specific address and hope that the Fortigate figures out which interface that address has. I guess this is sort of okay, but it just doesn’t give you as much control as your might want.

execute ping-options view
Ping Options:
        Repeat Count: 5
        Data Size: 56
        Timeout: 2
        Interval: 1
        TTL: 64
        TOS: 0
        DF bit: unset
        Source Address: auto
        Pattern:
        Pattern Size in Bytes: 0
        Validate Reply: no

Sending a ping out of the IP of an interface, where 72.84.109.43 is the interface bound address:

execute ping-options source 72.84.109.43
exec ping 4.2.2.2

The Fortigate will drop all packets sourced by any address other than ICMP from the address set to be the monitor address in the ECMP routing or other ICMP monitors (such as a part of a Load Balancer test).

But, you can monitor return packets easily:

diag debug enable
diag debug console timestamp enable
diag sniffer packet wan2 'host 72.84.109.43' 1

Where ‘wan2’ is the wan interface we want to send traffic out of, where 72.84.109.43 (our ‘exec ping-options source’ address) is bound.

When finished:

diag debug dis
diag debug reset
#ping-options will reset to default when your tty session ends

CloudShark

May 15, 2012 Leave a comment

CentOS el6 configure a dummy NIC and set up a network bridge

It’s encouraged that you test, but this will work.

In order to have the kernel pass all packets that are received on the NIC through the stack, you must configure a NIC bridge. If you do not do this and the NIC attempts to pass packets destined for an IP that isn’t routable (out of a different interface) or living on the box, the kernel will drop the packet, regardless of if the NIC is in promiscuous mode.

[09:31] == mbrownnyc [gateway/web/freenode/] has joined #Netfilter
[09:36] <whaffle> It is perfectly valid to have a "half-bridge" with only a single interface in it.
[09:37] <whaffle> Promisc mode will cause packets with {a dst MAC address that does not equal the interface's MAC address} to be delivered from the NIC into the kernel nevertheless.
[09:39] <whaffle> Furthermore, the linux kernel itself has a check for {packets with a non-local MAC address}, so that packets that will not enter a bridge will be discarded as well, even in the face of PROMISC.

Read more…

Fortigate VPN problems? Tell your Fortigate what to do.

November 11, 2011 11 comments

I spent a long while trying to bring up a tunnel to a third party over a dedicated extranet using a Fortigate and a Checkpoint.

The IPsec phase configs were very simple.  And we double checked several times that they were the same.  I even produced PCAP files at the interface to verify.

The majority of the complexity was in the network configuration.

Read more…

%d bloggers like this: