NAT PRECEDENCE
==============
1. Existing XLate
2. NAT 0
3. Satic NAT
3. Dynamic NAT, nat (inside)
Sunday, May 16, 2010
Tuesday, May 11, 2010
Sometimes Answers will be a Question !!!! Route Precedence
Recently I got a call from one of my followers, asking if we have three routes
10.10.10.0/24 via bgp
10.10.10.0/24 via ospf
10.10.0.0/16 via eigrp
which route will take for 10.10.10.1??
Now the basic funda is,
Route selection precedence is as follows
1. Most Specific route
2. AD value
3. Metric
Now here most specific routes are
10.10.10.0/24 via bgp
10.10.10.0/24 via ospf
Now AD value will come in the picture as tie breaker....
Take a look at the following Table for AD values
Default Administrative Distances
Connected 0
Static 1
eBGP 20
EIGRP (internal) 90
IGRP 100
OSPF 110
IS-IS 115
RIP 120
EIGRP (external) 170
iBGP 200
EIGRP summary route 5
Now the Answer is a question, Which BGP route was that, EBGP or IBGP??
If it is IBGP (AD value: 200), OSPF routes will get precedence…. Else it gonna take BGP routes (AD Value: 20)
10.10.10.0/24 via bgp
10.10.10.0/24 via ospf
10.10.0.0/16 via eigrp
which route will take for 10.10.10.1??
Now the basic funda is,
Route selection precedence is as follows
1. Most Specific route
2. AD value
3. Metric
Now here most specific routes are
10.10.10.0/24 via bgp
10.10.10.0/24 via ospf
Now AD value will come in the picture as tie breaker....
Take a look at the following Table for AD values
Default Administrative Distances
Connected 0
Static 1
eBGP 20
EIGRP (internal) 90
IGRP 100
OSPF 110
IS-IS 115
RIP 120
EIGRP (external) 170
iBGP 200
EIGRP summary route 5
Now the Answer is a question, Which BGP route was that, EBGP or IBGP??
If it is IBGP (AD value: 200), OSPF routes will get precedence…. Else it gonna take BGP routes (AD Value: 20)
Thursday, May 6, 2010
Checkpoint : How to Find the the Management Interface
It will be gud if you know the one who controls you.. So I was thinking how to get it in SPLAT and I was sure that they are storing it somewhere as they ask during configuration...
Finally I found the file:
more /etc/sysconfig/external.if
Finally I found the file:
more /etc/sysconfig/external.if
Sunday, May 2, 2010
GRE is like Girls!!! - GRE Tunnel in IPSEC - there will be twists in the Story...
Atleast I could not sleep for two dayz thinking, why GRE (Generic Routing Encapsulation) is required in IPSec when we run Dynamic Routing Protocols...
I talked to techies which I ever trust... all said "its required" but their answers were not enuf for me to sleep... eventually I reached office very early.. Started with my friend Google... My biggest confusion was IPSec works in Layer 3 , why they cant accommodate the dynamic routing protocol which runs on the same layer... Why it is not compatible... ??
Finally I found the answer... Its nothing but IPSec doesnt support Multicast Traffic.. I recalled my routing KB, yeas,,, most of the routing updates are done with Multicast.. So they needed a work around, and hence GRE into the scene... Now what is GRE....??
GRE is nothing but, type of a VPN, which create a virtual tunnel towards the destination from a particular source..
It hides the Multicast Packets, generated by your D. Routing Protocol and fools IPSEC, pretending that its a normal IP Packet.. I felt GRE is just like girls, hiding so many things in them and pretends everything normal...
Now, is GRE is only meant for IPSEC?? Answer is simplee.. NO.. whenever you want to hide something from your transit path, can do the same..
It seems nothing wrong in hiding something and fooling someone .... here is the twist, there will be overheads for these type of packets.. Did you forget the MSS value... ?? So beware those who fools someone.. there will be twists in the Story...
I talked to techies which I ever trust... all said "its required" but their answers were not enuf for me to sleep... eventually I reached office very early.. Started with my friend Google... My biggest confusion was IPSec works in Layer 3 , why they cant accommodate the dynamic routing protocol which runs on the same layer... Why it is not compatible... ??
Finally I found the answer... Its nothing but IPSec doesnt support Multicast Traffic.. I recalled my routing KB, yeas,,, most of the routing updates are done with Multicast.. So they needed a work around, and hence GRE into the scene... Now what is GRE....??
GRE is nothing but, type of a VPN, which create a virtual tunnel towards the destination from a particular source..
It hides the Multicast Packets, generated by your D. Routing Protocol and fools IPSEC, pretending that its a normal IP Packet.. I felt GRE is just like girls, hiding so many things in them and pretends everything normal...
Now, is GRE is only meant for IPSEC?? Answer is simplee.. NO.. whenever you want to hide something from your transit path, can do the same..
It seems nothing wrong in hiding something and fooling someone .... here is the twist, there will be overheads for these type of packets.. Did you forget the MSS value... ?? So beware those who fools someone.. there will be twists in the Story...
Thursday, April 22, 2010
Its always good to ask your partner first, but what if you dont have one / they are not responding properly?? - Checkpoint - Policy Synchronisation
How you will update the changes happened when you were out of home...
I would say its always good* to ask your better half .. Dont worry if they are not reponding / you dont have one, its temporary,,,!!! You can ask someone you trust (in Checkpoint its SCS)....
The same thing is happening when your cluster member returns/recovers in clustered environment of checkpoint..
When a failed cluster member recovers, it will first try to take a policy from one of the other cluster members. The assumption is that the other cluster members have a more up to date policy. If this does not succeed, it compares its own local policy to the policy on the SmartCenter server. If the policy on the SmartCenter server is more up to date than the one on the cluster member, the policy on the SmartCenter server will be retrieved. If the cluster member does not have a local policy, it retrieves one from the SmartCenter server. This ensures that all cluster members use the same policy at any given moment.
*Applicable for only who trust their partner :-p
I would say its always good* to ask your better half .. Dont worry if they are not reponding / you dont have one, its temporary,,,!!! You can ask someone you trust (in Checkpoint its SCS)....
The same thing is happening when your cluster member returns/recovers in clustered environment of checkpoint..
When a failed cluster member recovers, it will first try to take a policy from one of the other cluster members. The assumption is that the other cluster members have a more up to date policy. If this does not succeed, it compares its own local policy to the policy on the SmartCenter server. If the policy on the SmartCenter server is more up to date than the one on the cluster member, the policy on the SmartCenter server will be retrieved. If the cluster member does not have a local policy, it retrieves one from the SmartCenter server. This ensures that all cluster members use the same policy at any given moment.
*Applicable for only who trust their partner :-p
Monday, April 19, 2010
Checkpoint : fw ctl pstat - Thanks Shanawazzzzz
Yeas.... I remember his name, "Shanawaz", asked me a bloody question (at least for me that time) .. What is the command “fw ctl pstat” used for.. I was clarifying the question by asking him fw ctl p???? what.. (As if am another PhoneBOY)
Literally he was laughing at me in the video conferencing…. Ofcoz I was thinking what to laugh….. !!! In a way I was happy, at least he was laughing at me just in front. Thank God…. that laugh ended up with my CCSA Certification.. of coz they told me a sorry at the end of our discussion.. haha .. Nothing new... as am in TRANS of another "Sorry"..
Now what is fw ctl pstat??
According to me, its nothing but a fw command with which we can monitor the heath of your CP box., especially Syc Status.. Am sure that you will love this command and say thanks for CP for this……
As I have mentioned in my previous post, SYC is so important (at least this time not start but to CONTINUE)
Am taking an example to explain the same.. here we go…….
Sync:
Version: new
Status: Able to Send/Receive sync packets
Sync packets sent:
total : 466729198, retransmitted : 241305, retrans reqs : 6089, acks : 809
Sync packets received:
total : 77283541, were queued : 6715, dropped by net : 6079
retrans reqs : 37462, received 175 acks
retrans reqs for illegal seq : 0
dropped updates as a result of sync overload: 0
Delta Sync memory usage: currently using XX KB mem
Callback statistics: handled 138 cb, average delay : 2, max delay : 34
Number of Pending packets currently held: 1
Packets released due to timeout: 18
Explanation:
Version: new
This line must appear if synchronization is configured (versions above 4.1)
Status: Able to Send/Receive sync packets
If sync is unable to either send or receive packets, there is a problem
Sync packets sent:
total : 466729198, retransmitted : 241305, retrans reqs : 6089, acks : 809
TOTAL number of sync packets is non-zero and increasing
RETRANS REQS may increase under load
Sync packets received:
total : 77283541, were queued : 6715, dropped by net : 6079
QUEUED value never decreases - A non-zero value does not indicate a problem
DROPPED BY NET number may indicate network congestion
The “dropped by net” counter is incremented when the cluster member receives a sync packet with a sequence number which is higher than the expected seq num. This means packets with lower seq where lost somewhere along the way, and we need to find out where.
retrans reqs : 37462, received 175 acks
RETRANS REQS growing very fast may indicate that the load is becoming too high
retrans reqs for illegal seq : 0
May indicate a sync problem
dropped updates as a result of sync overload: 0
In a heavily loaded system, the cluster member may drop synchronization updates sent from another cluster member
Delta Sync memory usage: currently using XX KB mem
This statistic only appears for a non-zero value.
It requires memory only while full sync is occurring at other times, Delta sync requires no memory
Callback statistics: handled 138 cb, average delay : 2, max delay : 34
This statistic only appears for a non-zero value.
AVERAGE DELAY should be 1-5 packets, otherwise indicates an overload of sync traffic
Number of Pending packets currently held: 1
This statistic only appears for a non-zero value.
Packets released due to timeout: 18
This statistic only appears for a non-zero value.
If the it is large (more than 100 pending packets), and the "Number of Pending packets currently held" is small, you should take action to reduce the number of pending packets.
To tackle this problem, try google "Reducing the Number of Pending Packets".
Hey.. Now who is shanawaz….!!!
He was my interviewer (Not revealing his company), Anyway.. Thanks Dude for asking me that….
Literally he was laughing at me in the video conferencing…. Ofcoz I was thinking what to laugh….. !!! In a way I was happy, at least he was laughing at me just in front. Thank God…. that laugh ended up with my CCSA Certification.. of coz they told me a sorry at the end of our discussion.. haha .. Nothing new... as am in TRANS of another "Sorry"..
Now what is fw ctl pstat??
According to me, its nothing but a fw command with which we can monitor the heath of your CP box., especially Syc Status.. Am sure that you will love this command and say thanks for CP for this……
As I have mentioned in my previous post, SYC is so important (at least this time not start but to CONTINUE)
Am taking an example to explain the same.. here we go…….
Sync:
Version: new
Status: Able to Send/Receive sync packets
Sync packets sent:
total : 466729198, retransmitted : 241305, retrans reqs : 6089, acks : 809
Sync packets received:
total : 77283541, were queued : 6715, dropped by net : 6079
retrans reqs : 37462, received 175 acks
retrans reqs for illegal seq : 0
dropped updates as a result of sync overload: 0
Delta Sync memory usage: currently using XX KB mem
Callback statistics: handled 138 cb, average delay : 2, max delay : 34
Number of Pending packets currently held: 1
Packets released due to timeout: 18
Explanation:
Version: new
This line must appear if synchronization is configured (versions above 4.1)
Status: Able to Send/Receive sync packets
If sync is unable to either send or receive packets, there is a problem
Sync packets sent:
total : 466729198, retransmitted : 241305, retrans reqs : 6089, acks : 809
TOTAL number of sync packets is non-zero and increasing
RETRANS REQS may increase under load
Sync packets received:
total : 77283541, were queued : 6715, dropped by net : 6079
QUEUED value never decreases - A non-zero value does not indicate a problem
DROPPED BY NET number may indicate network congestion
The “dropped by net” counter is incremented when the cluster member receives a sync packet with a sequence number which is higher than the expected seq num. This means packets with lower seq where lost somewhere along the way, and we need to find out where.
retrans reqs : 37462, received 175 acks
RETRANS REQS growing very fast may indicate that the load is becoming too high
retrans reqs for illegal seq : 0
May indicate a sync problem
dropped updates as a result of sync overload: 0
In a heavily loaded system, the cluster member may drop synchronization updates sent from another cluster member
Delta Sync memory usage: currently using XX KB mem
This statistic only appears for a non-zero value.
It requires memory only while full sync is occurring at other times, Delta sync requires no memory
Callback statistics: handled 138 cb, average delay : 2, max delay : 34
This statistic only appears for a non-zero value.
AVERAGE DELAY should be 1-5 packets, otherwise indicates an overload of sync traffic
Number of Pending packets currently held: 1
This statistic only appears for a non-zero value.
Packets released due to timeout: 18
This statistic only appears for a non-zero value.
If the it is large (more than 100 pending packets), and the "Number of Pending packets currently held" is small, you should take action to reduce the number of pending packets.
To tackle this problem, try google "Reducing the Number of Pending Packets".
Hey.. Now who is shanawaz….!!!
He was my interviewer (Not revealing his company), Anyway.. Thanks Dude for asking me that….
Avoid Breakup... By Any Means : CheckPoint : Check Firewalls in Sync
Every "TRUE" Relation needs syncronisation..
Most of the relations are breaking up just because of lack of Communication, May be a Sync Problem..
The same problem which we face/faced in normal life can happen in a clustered environment, will lead into misbehaviour in cluster node... So before the "BreakUP" happens try the following in case of checkpoint... However am not good to give a similar solution in real LIFE...
How can I check that my Checkpoint Cluster is in Sync ?
In order to ensure that the State Tables of all your nodes within your Checkpoint Cluster are syncronised you will need to check the #VALS of your State Table summary on each node.
You may find that these figures aren`t identical but this is just down to the delay/latancy in which occurs between State Syncronisations. You should only be concerned if the values are hunreds or even thousands out.
The best way to view the State Table summaries (on SPLAT based firewalls) is to run the command watch 'fw tab -t connections -s'.
Check the State Tables on both nodes, checking for the #VAL totals. It should be somewhat same.. Linearly same.. :-)
So whenever possible, check SYNC Regularly to avoid BREAKUP....
Most of the relations are breaking up just because of lack of Communication, May be a Sync Problem..
The same problem which we face/faced in normal life can happen in a clustered environment, will lead into misbehaviour in cluster node... So before the "BreakUP" happens try the following in case of checkpoint... However am not good to give a similar solution in real LIFE...
How can I check that my Checkpoint Cluster is in Sync ?
In order to ensure that the State Tables of all your nodes within your Checkpoint Cluster are syncronised you will need to check the #VALS of your State Table summary on each node.
You may find that these figures aren`t identical but this is just down to the delay/latancy in which occurs between State Syncronisations. You should only be concerned if the values are hunreds or even thousands out.
The best way to view the State Table summaries (on SPLAT based firewalls) is to run the command watch 'fw tab -t connections -s'.
Check the State Tables on both nodes, checking for the #VAL totals. It should be somewhat same.. Linearly same.. :-)
So whenever possible, check SYNC Regularly to avoid BREAKUP....