Sunday, June 16, 2013

Fortimail Tips & Tricks

Here's a few tips that I would like to share about the Fortimail Appliance;

1st  If you want to clear all mail statistics , you can easily conduct this operation from the cmd line;

You can also write them out to a file b4 execution of the clearing.
NOTE :  I don't know of any way to download the statistics off the  unit directory after doing this


2nd Have you ever had stale greylisting  entries in the display , and new ones are not populating? Will you can  clear the greylist database from the cli.



3rd

The FortiMail appliance allows you to download the logs from the gui, you can use these logs via scripts to manipulate collection of details such as; client_ip; dispositions;etc...



4th

Remember you can write layer3  ACLs to block by address for receive or outgoing;




This way, you don't have to wait for your firewall team to block anything for you :)

5th

For Secured SMTP you need to check the following box.


Lastly, when updating software, always  backup the cfg. I've seen problems where rules where lost during a OS update


Ken Felix
Freelance Network/Security Engineer
kfelix  ----at---hyperfeed ---dot---com

     ^          ^
= (  @   @ ) =
           O
         /    \
 

Thursday, June 13, 2013

SNMPv3 on SRX Junos ( user and views )

In this post we will look at SNMPv3 support and views creations.

SNMP v3 support is available in  junos and the SRX platform for quite some time now. It's quite simple to set up. Let's recap what SNMPv3 provides;

It supports encryption ( privacy ) and authentication ( who has access )
It's backward compatible with  communities 
It supports views ( even v1 & v2c supports views btw )

Okay let's look a very basic v3 cfg;



set snmp v3 usm local-engine user nms  authentication-md5 authentication-password mypasswordhere
set snmp v3 usm local-engine user nms privacy-des privacy-password mypasswordhere
set snmp v3 vacm security-to-group security-model usm security-name nms group groupnms
set snmp v3 vacm access group groupnms  default-context-prefix security-model any security-level privacy  read-view all
set snmp v3 vacm access group groupnms  default-context-prefix security-model any security-level privacy write-view all
set snmp view all oid .1
set snmp contact hyprops

The above is from my management & polling station. And for this SRX we are allowing both the Authentication & Privacy ( authPriv ) and my view  is named "all". And within the view "all", we have allowed  all views with in the .1 family ( so pretty much the whole tree  for .iso  & the   ISO assigned oids  or the start of the tree with the MIB walk )

My SNMPv3 user == "nms"  and he belongs to  the group known as "groupnms"
The group "groupnms" has a view ( "all" ) for the security level  "privacy" and for both read/write access


Okay see how simple the above was ? 


We  can craft various views to ensure we give the appropiate user the right to read/write as required by the SNMP manager. Typically in my setups, I  have numerous views depending on  the SNMP manager functions & roles.

( e.g  NMS polling station ( cacti ) and another for  NMS monitor ( opsview/nagios ) )

Okay now let's look a more complex setup that leverage a more specific view ;



set snmp v3 usm local-engine user nmssys  authentication-md5 authentication-password hyprf33d3efSnMpv3
set snmp v3 usm local-engine user nmssys privacy-des privacy-password hyperFe3dP3nL921h

set snmp v3 vacm security-to-group security-model usm security-name nmssys group hyperfeedpen

set snmp v3 vacm access group hyperfeedpen  default-context-prefix security-model any security-level privacy read-view hypr5387
set snmp v3 vacm access group hyperfeedpen  default-context-prefix security-model any security-level privacy write-view hypr5387
set snmp view hypr5387 oid .1.3.6.1.4.1.5387 include
set snmp view hypr5387 oid .1.3.6.1.4.1.2636.3.11 include
set snmp view hypr5387 oid  .1.3.6.1.4.1.2636.4 include
set snmp view hypr5387 oid  .1.3.6.1.4.1.2636.1.1.1.2 include
set snmp view hypr5387 oid  .1.3.6.1.4.1.2636 exclude
set snmp view hypr5387 oid  ifIndex  included
set snmp view hypr5387 oid  ifName included

set snmp v3 snmp-community  NMSac#ssH678 security-name nmssys
set snmp contact  nms@hyperfeed.net

Okay the above provide a few oid that I've allowed and a few that I want to disallow for this view and user using a few juniper  oids and  the full range of oid under my own PEN " 5387 IANA " and a few common interface oid. I have a community string  also created.


Another example and more common

I could have create a view to exclude certain details and apply these to my group and user;

e.g
set snmp view mycustomer oid  ifDescr .6 include
set snmp view mycustomer oid  ifName.6 include

set snmp view mycustomer oid  ifOutOctets.6 include
set snmp view mycustomer oid  ifInOctets.6 include
set snmp view mycustomer oid  ifType.6 include
set snmp view mycustomer oid  ifAlias.6 include


The above would allow the user/group  to query the above  objects and only those objects in the "mycustomer" view & for the interface index ID of ".6"

 Great for when you want to accommodate a client & allow them to graph a port, but restrict his/her view to just that port.


With SNMPv3 we can use  the common  snmptools;    snmpwalk or snmpget  & to test the  "views" and configuration parameters;


e.g

snmpwalk -u <username" -v3  -O ne  -l authPriv -x md5 -X <authentication pass phrase> -x des -X <privacy passphrase > ip_address .1.3.6.1.4.1.5387

( the above would walk all in the  Organization   of registered  "HyperFeed"  starting  at .1.3.6.1.4.1.5387* )

Things to key in mind;

  • ciphers are limited to DES or AES128 ( not sure if 3des is support in any Junos release )
  • you can provide  further restriction by enabling a host ACL filter to restrict the SNMP manager access by ip_address targets
  • passphrases need to be  8 characters or more , and try to avoid special characters like a ! or *
  • A user can be a member of just  one group ;  for both the read or write
 
When trouble-shooting;


  • try to identify the problem
  • is a credential related matter ( a wrong user and/or password or auth/privacy level )
  • or is it a ACL ( port 161/udp )
  • or is it a encryption protocol/hash mismatch



Good luck and remember to diagnose you snmp issues and configuration, based on what errors you get;



FWIW: Your SNMPviews can be different for both read or write & don't have to match. 


" I try to avoid taking a Hilter approach and place extremely tight  SNMPviews . If you don't know what your SNMPmanager might poll. I 've spent countless hours trouble-shooting  why Nagios is timeout or failing on a query and come to find out, we where blocking it from  our view   "


Ken Felix
Freelance Network/Security Engineer
kfelix  ------a@t --------hyperfeed ---.----- com


    ^        ^
= ( @    @ ) =
             )
        /   ~   \


Tuesday, June 11, 2013

CDN and ipv6

Content Delivery Network providers have been slow  in providing  content for ipv6 clients, but the growth is moving forward.

Take this link  http://www.akamai.com/ipv6/

This is akamai tracking of ipv6 content delivery. What you will find  interesting, the number are  moving at a snail's pace.

A few reasons as to why;

  • lacking of knowledge in the enterprise sector
  • lack of any customers demanding it
  •  security  awareness for WAF/PROXIES/FILTER/SSL-INSPECTION is hit or miss
  • lack of DDoS mitigation service providers 
  • overall budgets in  our tight economy for transition to ipv6 is small
All of these are  factors , stuns the movement to provide content for the ipv6 segment. Take my  dayjob, we have connection to the ipv6  backbone , but as of this date; " we do not have one  public facing  server on the ipv6 network".

Same things goes  in that we are a mitigation  company, but we  really can't mitigate anything as far as ipv6 traffic goes.

 Next,
 look at  how many host based AV/Malware software that supports ipv6? ( very few )

So all of these factors are major reasons as to why content on the ipv6 network is at a crawl. Here's a listed on CDN providers that are ipv6 awared;


Akamai
edgecast
limelight
level3
cloudflare


here's some good links to learn more about  these ipv6 CDN providers

http://www.edgecast.com/ipv6/
http://www.limelight.com/ipv6
https://www.cloudflare.com/ipv6


Ken Felix
Freelance Network/Security Engineer
kfelix   --a@t-- hyperfeed ---d.t--com


Saturday, June 8, 2013

Packet Forgery

In this discussion, we will look at packet forging tool known simply as "sendip".

Sendip is a packet utility tool that comes in handy for typical security personnel. Great for  crafting packets to check firewall policies or ips/idp signatures. Or in some case to  check the behavior of a network device or server.

Sendip used various modules  and supports ipv4 and v6. Each module works on a dependency model

e.g

for a icmp message

ipv4+ icmp

for a udp packet

ipv4 + udp


With the dual ipv4/ipv6  stack support, you can build a slew of options, depending on the modules you enable & the options or switches you use.

Here's a terse output of the udp module;

(snip)
Modules are loaded in the order the -p option appears.  The headers from
each module are put immediately inside the headers from the previos model in
the final packet.  For example, to embed bgp inside tcp inside ipv4, do
sendip -p ipv4 -p tcp -p bgp ....


Modules available at compile time:
    ipv4 ipv6 icmp tcp udp bgp rip ntp



Arguments for module udp:
   -us x    UDP source port
             Default: 0
   -ud x    UDP destination port
             Default: 0
   -ul x    UDP packet legnth
             Default: Correct
   -uc x    UDP checksum
             Default: Correct


And for tcp , we have way more options;

 (snip)
Modules available at compile time:
    ipv4 ipv6 icmp tcp udp bgp rip ntp



Arguments for module tcp:
   -ts x    TCP source port
             Default: 0
   -td x    TCP destination port
             Default: 0
   -tn x    TCP sequence number
             Default: Random
   -ta x    TCP ack number
             Default: 0
   -tt x    TCP data offset
             Default: Correct
   -tr x    TCP header reserved field EXCLUDING ECN and CWR bits
             Default: 0
   -tfe x    TCP ECN bit (rfc2481)
             Default: 0 (options are 0,1,r)
   -tfc x    TCP CWR bit (rfc2481)
             Default: 0 (options are 0,1,r)
   -tfu x    TCP URG bit
             Default: 0, or 1 if -tu specified (options are 0,1,r)
   -tfa x    TCP ACK bit
             Default: 0, or 1 if -ta specified (options are 0,1,r)
   -tfp x    TCP PSH bit
             Default: 0 (options are 0,1,r)
   -tfr x    TCP RST bit
             Default: 0 (options are 0,1,r)
   -tfs x    TCP SYN bit
             Default: 1 (options are 0,1,r)
   -tff x    TCP FIN bit
             Default: 0 (options are 0,1,r)
   -tw x    TCP window size
             Default: 65535
   -tc x    TCP checksum
             Default: Correct
   -tu x    TCP urgent pointer
             Default: 0
   -tonum x    TCP option as string of hex bytes (length is always correct)
             Default: (no options)
   -toeol      TCP option: end of list
   -tonop      TCP option: no op
   -tomss x    TCP option: maximum segment size
   -towscale x    TCP option: window scale (rfc1323)
   -tosackok      TCP option: allow selective ack (rfc2018)
   -tosack x    TCP option: selective ack (rfc2018), format is l_edge1:r_edge1,l_edge2:r_edge2...
   -tots x    TCP option: timestamp (rfc1323), format is tsval:tsecr


Okay let's look at me crafting the following;

sendip -v  -p ipv4 -is 10.253.84.200 -p tcp -tomss 6655 -ts 3400 -td 80 -ifr 1 -ii 1234  www.example.com

ip-ident         1234
ip reserved bit toggle on
Protol      #6 (tcp)
Source-port       3400
Dest-port    80
MSS          6655

I'm also sourcing this packet with my real ip_address, since my new provider has unicast verification enabled :(

A packet capture at the target looks  something like the below;

Internet Protocol, Src: 50.112.xx.xxx (50.112.xxx.xxx), Dst: xxx.xxx.154.11 (xxx.xxx.154.11)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 44
    Identification: 0x04d2 (1234)   <--- ip.identification
    Flags: 0x08
        1... = Reserved bit: Set     <--------my reserved bit set
        .0.. = Don't fragment: Not set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 242
    Protocol: TCP (0x06)
    Header checksum: 0x71fe [correct]
        [Good: True]
        [Bad : False]
    Source: 50.112.xxx.xxx (50.112.xxx.xxx)
    Destination: xxx.xxx.154.11 (xxx.xxx.154.11)
Transmission Control Protocol, Src Port: 3400 (3400), Dst Port: 80 (80), Seq: 0, Len: 0
    Source port: 3400 (3400)     <----source port
    Destination port: 80 (80)     < --- destination port
    Sequence number: 0    (relative sequence number)
    Header length: 24 bytes
    Flags: 0x02 (SYN)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set
        ...0 .... = Acknowledgment: Not set
        .... 0... = Push: Not set
        .... .0.. = Reset: Not set
        .... ..1. = Syn: Set
        .... ...0 = Fin: Not set
    Window size: 65535
    Checksum: 0xea68 [correct]
        [Good Checksum: True]
        [Bad Checksum: False]
    Options: (4 bytes)
        Maximum segment size: 6655 bytes
   <----- MSS value

So if you are curious about ip packet creation,  and detection; " sendip is a must". Imho is simpler to use than scapy,  but with scapy you can do more get more done. For quick easy packet manipulation, nothings beats sendip. I will follow up with a post on scapy.


Ken Felix
Freelance Network/Security Engineer
kfelix    ---at--- hyperfeed ----dot---com

     ^       ^
=(  0   @ )=
      /  * \

Friday, June 7, 2013

My pfSense giving the bird ( update )

Will here's some good news; " my upstream peer did find  a issue in his OpenBGP configuration".

He found a problem with his export policy, and made  the following adjustments
( snippet from  the email )

So now the bad news, my Bird6 client is not accessing the routing engine. As  I stated before, " the the Bird routing daemon is just okay! ". It far from being stable and mature in a lot of environments.



So with the lack of access to the Bird6 daemon, I can't even monitor the sessions or see what ipv6 prefixes where learned. This only leaves me the ability to  dump on the BGP keepalives,  &  to determine that we are indeed established  & from a BGP standpoint.



So I'm now reverting back to my original  OpenBGP configuration, and will have to wait till the  upstream peer accepts my connection;


and tcpdump shows the following ( resets from my upstream peer at 2607xxxxxxx.1 );



So I will wait :)


And now we have a  bgp session;

As you can see, only one ipv6 prefix.



Both opensource  routing daemons can present  very unique  problems and issues in it's own. So you have to pick the one that feels the best &  right for your solution. OpenBGP probably has more users overall, so I rather stay with it. You can read more at the below link;

http://en.wikipedia.org/wiki/OpenBGPD 
http://www.openbsd.org/cgi-bin/man.cgi?query=bgpd&sektion=8&arch=&apropos=0&manpath=OpenBSD+Current
http://www.openbsd.org/cgi-bin/man.cgi?query=bgpctl

Using it both for my  ipv4/ipv6 bgp peers,  and with the natural support in pfSense, it  make more sense to use  OpenBGP than Bird. In the longer run, we can only hope for better diagnostics and debugging within both of the opensource routing daemons. This also means better logging information & details.

This is where  commerical systems shine the best at. You have a  better overall support structure and some type of technical source to lean on. With any  opensource  solution, you have only a forum and wide internet audience.

Ken Felix
Freelance Network/Security Engineer
kfelix ---a-t--- hyperfeed ----d-o-t---com

    ^      ^
= ( *   * ) =
        @


Tuesday, June 4, 2013

How to control locally originated traffic from your cisco router?


How to control locally originated traffic from your cisco router?



If you did’t know by now, any outbound ACLs on a interface,  does not filter traffic originated from the router. Look at this exhibit

router3825#sh run int gi 0/0

Building configuration...



Current configuration : 302 bytes

!

interface GigabitEthernet0/0

 ip address 1.1.1.253 255.255.255.0

 ip nbar protocol-discovery

 ip virtual-reassembly in

 duplex auto

 speed auto

 media-type rj45

 analysis-module monitoring

 ipv6 address 2001:470:C021:1::1/64

 ipv6 enable

 ipv6 nd prefix default 360 120

 ipv6 nd ra lifetime 340

end



The ACL is used and verify for traffic that transient  the router interfaces.
Now let’s add a ACL restricting pings from 1.1.1.253 ( gi 0/0 ) ;


router3825#config t

Enter configuration commands, one per line.  End with CNTL/Z.

router3825(config)#ip access-list ext noicmp

router3825(config-ext-nacl)#deny icmp host 1.1.1.253 any

router3825(config-ext-nacl)#permit ip any any

router3825(config-ext-nacl)#int gi 0/0

router3825(config-if)#ip acces

router3825(config-if)#ip access-group noicmp out

router3825(config-if)#

router3825(config-if)#end




and here’s we will try to  pinging a dhcp host that's locally connected to the router;

router3825#show ip dhcp bin

Bindings from all pools not associated with VRF:

IP address          Client-ID/                            Lease expiration        Type

                            Hardware address/

                            User name

1.1.1.1             0100.1f5b.ea0a.fa       Jun 04 2013 01:53 AM    Automatic


router3825#ping 1.1.1.1 source 1.1.1.253

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.253

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

router3825#


and let's double check that the ACL has been applied;

router3825#show ip int gi 0/0 | incl acc

  Outgoing access list is noicmp            <--------

  Inbound  access list is not set

  IP output packet accounting is disabled

  IP access violation accounting is disabled


router3825#sh access-list noicmp       

Extended IP access list noicmp

    10 deny icmp host 1.1.1.253 any

    20 permit ip any any

router3825#


Okay, so how can we filter traffic outbound that originates from the route?

Easy, we use a route-map+acl and a local route policy

1st the ACL

ip access-list extended controlme

 permit icmp host 1.1.1.253 any echo

 deny   ip any any


2nd route-map
!

route-map mylocal permit 50

 match ip address controlme

 set interface Null0

!

route-map mylocal permit 100

!




And now the configuration  for our local-policy

config t

    ip local policy route-map mylocal

 end

And to verify;


router3825#show ip local  policy

Local policy routing is enabled, using route map mylocal

route-map mylocal, permit, sequence 50

  Match clauses:

    ip address (access-lists): controlme

  Set clauses:

    interface Null0

  Policy routing matches: 5 packets, 500 bytes

route-map mylocal, permit, sequence 100

  Match clauses:

  Set clauses:

  Policy routing matches: 418 packets, 81963 bytes

router3825#


and we can see that pings request with fail from the router, but it will response to external pings and send it's echo-response ;

router3825#show arp | incl 1.1.1.1

Internet  1.1.1.1                 4   001f.5bea.0afa  ARPA   GigabitEthernet0/0

router3825#ping 1.1.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

router3825#ping 1.1.1.1 source 1.1.1.253

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.253

.....

Success rate is 0 percent (0/5)

router3825#


But the loopback will succeed;

router3825#show ip int br | incl Loop

Loopback0                  1.0.0.2         YES NVRAM  up                    up     

router3825#ping 1.1.1.1 source 1.0.0.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

Packet sent with a source address of 1.0.0.2

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

router3825#


And from host 1.1.1.1 we can ping the loopback or interface with no problems;

sh-3.2# netstat -nr -f inet | grep default

default            1.1.1.253          UGSc           16        0     en0




sh-3.2# ping 1.1.1.253

PING 1.1.1.253 (1.1.1.253): 56 data bytes

64 bytes from 1.1.1.253: icmp_seq=0 ttl=255 time=0.657 ms

64 bytes from 1.1.1.253: icmp_seq=1 ttl=255 time=0.593 ms

^C

--- 1.1.1.253 ping statistics ---

2 packets transmitted, 2 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 0.593/0.625/0.657/0.032 ms

sh-3.2# ping 1.0.0.2

PING 1.0.0.2 (1.0.0.2): 56 data bytes

64 bytes from 1.0.0.2: icmp_seq=0 ttl=255 time=0.738 ms

64 bytes from 1.0.0.2: icmp_seq=1 ttl=255 time=0.759 ms

^C

--- 1.0.0.2 ping statistics ---

2 packets transmitted, 2 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 0.738/0.748/0.759/0.011 ms

sh-3.2#



You can get very creative on filtering traffic from the router directly, and via this approach.

Ken Felix
Freelance Network/Security Engineer
kfelix   ----at--  hyperfeed ---dot--- com


    ^     ^
= ( *   * )=
        @

      #               
      ################
      #       #
              ##
      ##########
      #########
 #             #
 ##         ####
   ##   ###### #
      #####
          ###
              ##
               #
 ###############
       #      
      #        #
      ##      ##
       ########
         ###
       ########
      #   #    #
      #   #    #
      #   #  ##
          ####
      #        #
      ##########
      #      #
              #
            ####
             ##
               #
      ###############
      #        #     #
               #   ###
                    
         ###
       ########
      #   #    #
      #   #    #
      #   #  ##
          ####
         ###
       ########
      #   #    #
      #   #    #
      #   #  ##
          ####
         ####
       ########
      #        #
      #        #
      ################
      ################






Saturday, June 1, 2013

Giving the Bird to Pfsense OpenBGD

My problems with  OpenBGP & what started out as  my upgrade to  the 2.1 release-candidate,  had  made me re-think about using  the  Bird routing daemon.

Bird is a open source  routing  engine,  that's growing in popularity. It does the same thing as Zebra/Quagga  routing daemon and seems  okay.

It's not as strongly support  as the legacy GateD routing daemon,  and like GateD, it uses a routing monitor client to view and control parts of the routing engine.

Birdc vrs GateD  gdc ( Bird vrs GateD)

you can find more information here;

http://bird.network.cz/

and

http://en.wikipedia.org/wiki/Merit_Network
http://www.merit.edu/services/


btw: GateD was great for OSPF routing and I ran a complete small ISP network off GateD back in the late 90s on a mix of Sun SparcStations and x386 platforms

( a little bit on my past history with Bird )

I've used Bird for route injection &  with over 300K /32 routes,  and it held up  with little problems, but any traffic forwarding thru the box and along with bgp+ospf instability, seem to have a direct impact  to the Bird daemon uptime. So I'm not 100%  confident in bird in a full blown  production center.  

We had numerous nights of logining into our bird route-injector and to find the daemon had died. This was under FreeBSD & with a  dedicate  HP hardware btw. We also  used Bird for locally  redundant  Bgp-RouteRefelector Servers. 

The  price of  2each simple Dell R610 servers ( freebsd+Bird), was much cheaper than a single cisco ISR2900 :)



Now let's look at Bird;

It support  rip, ospf, & the bgp routing protocols and with the means to control route export & importation. To install it under pfsense, I had to resort to a manual pkg_add since the pfSense distribution doesn't have a pkg source available.


Next,

After you've installed  the Bird pkg, you will need to craft your configuration file. Based on what your doing, that could be a few lines,  or a few hundred lines.

Here's a preview of  my configuration approach,  which is for the very basic route importation for Bgp.

( which is the default for BGP )

Okay simple! 

We've define a few global configuration items, and then we move into the "protocol bgp" section to  define our neighbor.

Once you have the cfg setup, you could then use a simple cmd to check the cfg via the following;


Here my cfg file sits in /etc and is named bird6.conf


Okay,

 So after you have the bird-cfg checked out, we can start the  process via; 

bird6 -c /etc/bird6.conf -s 1001

This will start the process and set the control channel for socket 1001.

You can now confirm it's started via the system log and or the following;



Okay after it's started;
We can jump into the client monitor via the Bird client ( birdc6 -s 1001 )





If all was good and we had a bgp session up.  You could verify  with any of the following;

show protocol all
show protocol bgp1

But in my case I was displayed an error;


I did have it started a few times,   and we pulled in 12k+ ipv6 routes before it closed the session & with the same "malform attribute error", that was seen under OpenBGP.

I believe this is a problem in the  BGP- UPDATEs from my arpnetwork peer. I'm still investigating this matter , but since the same 2 errors came in and with 2 different routing daemons, I think it's an update issue and from my upstream OpenBGP peer.

NOTE:  Btw, on this pfsense host, I'm running a OpenBGP instance for ipv4 and Birdv6 for ipv6. 

Here's some a screen shots on when it working & correctly;





And the system log file when it fails and our BGP session is torn down ;
  ( snip)

I do  have a running pcap on my host, and later I'm going to diagnose it with wireshark/tshark and inspect the last bgp UPDATES & right before the tear down.



I believe my upstream peer  has something hosed up. And as a side task, I'm in the process of crafting a  GRE tunnel between my pfSense host, and to one of my Juniper J router.

We will establish a  bgp-v6 peer between the these two devices,  and validate that we do have stable bgp establishment for ipv6 peers & with Bird6. This could be a OS stack issues within pfSense 2.1rc. I'm only guessing as to what could be the issue(s) as of this time.

fwiw:

If anybody wants to establish a bgp peering session over a GRE tunnel for testing, please contact  me at the below email.

This host is dual homed on  a ipv4/6 backbone. And the problem with bgp establishments, seems to be  ipv6 related. So I would like to  test ipv6 connectivity to various other bgp peers, & using  Bird6.


Ken Felix
Freelance Network/Security Engineer
kfelix --at-- hyperfeed --dot-- com

Stay tuned !

     ^        ^
= ( @   @ ) =
          o
        /    \