I wanted to post something tonight because I haven't posed in a while. Id like to cover "bonding" two T1s together to make one larger pipe. I mean going from 1.54Meg to 3Meg. Who doesn't love more bandwidth? So here is what I did on a Cisco 1841 router.
First, you need to configure the controller interfaces:
controller T1 0/1/0
framing esf
linecode b8zs
channel-group 0 timeslots 1-24
!
controller T1 0/1/1
framing esf
linecode b8zs
channel-group 1 timeslots 1-24
Next, lets configure the Multilink interface. This will be used to put the IP address on:
interface Multilink1
ip address 172.24.0.2 255.255.255.252
ppp multilink
ppp multilink group 1
Next, lets configure the serial interfaces that the T1s will plug into. These will be "bonded" together with the "ppp mulitlink group 1" command.
interface Serial0/1/0:0
no ip address
encapsulation ppp
ppp multilink
ppp multilink group 1
!
interface Serial0/1/1:1
no ip address
encapsulation ppp
ppp multilink
ppp multilink group 1
!
Thats it. Now you have 3Meg instead of 1.54Meg. Not too shabby.
Wednesday, November 30, 2011
Monday, November 14, 2011
Brocade (Foundry): Error - invalid virtual ethernet interface number.
I have run into a nuisance on occasion on a layer 3 brocade switch, that when I want to go into the VE interface, I cant. Here is what I mean:
BR-telnet@DC_CORE_1(config-vlan-10)#int ve 10
Error - invalid virtual ethernet interface number.
As you can see above, when I try to go into the virtual ethernet interface 10, I get an error saying its invalid. Well, the reason is that you have to go into the vlan first and put a ethernet port in the vlan to make it "appear", if you will. Until you put an interface in the vlan, you will not be able to go into the VE interface. See below example.
BR-telnet@DC_CORE_1(config)#vlan 10
BR-telnet@DC_CORE_1(config-vlan-10)#tagged eth 1/1
Added tagged port(s) ethe 1/1 to port-vlan 10.
BR-telnet@DC_CORE_1(config-vlan-10)#router-interface ve 10
BR-telnet@DC_CORE_1(config-vlan-10)#int ve 10
BR-telnet@DC_CORE_1(config-vif-10)#
I run into this a lot, and I tend to forget I have to have a port in the vlan first. I cant go in and do VRRP or put an IP address on the virtual ethernet interface until I get a port in that vlan. Just a thought for today.
BR-telnet@DC_CORE_1(config-vlan-10)#int ve 10
Error - invalid virtual ethernet interface number.
As you can see above, when I try to go into the virtual ethernet interface 10, I get an error saying its invalid. Well, the reason is that you have to go into the vlan first and put a ethernet port in the vlan to make it "appear", if you will. Until you put an interface in the vlan, you will not be able to go into the VE interface. See below example.
BR-telnet@DC_CORE_1(config)#vlan 10
BR-telnet@DC_CORE_1(config-vlan-10)#tagged eth 1/1
Added tagged port(s) ethe 1/1 to port-vlan 10.
BR-telnet@DC_CORE_1(config-vlan-10)#router-interface ve 10
BR-telnet@DC_CORE_1(config-vlan-10)#int ve 10
BR-telnet@DC_CORE_1(config-vif-10)#
I run into this a lot, and I tend to forget I have to have a port in the vlan first. I cant go in and do VRRP or put an IP address on the virtual ethernet interface until I get a port in that vlan. Just a thought for today.
How To Configure A Stack On A Brocade (Foundry) FCX648SHPOE
I am often asked to setup a stack with the FCX648SHPOE Brocade switches. This is a pretty simple process to do. Connect the stacking cables in the back appropriately (up on first switch to down on the second switch, and vice versa for controller redundancy). Boot them up and then go through the following configuration:
config t
stack enable
exit
stack secure
config t
stack mac XXXX.XXXX.XXXX <--- Primary switch MAC address
After the "stack secure" command, the stack will start to configure. It will take a few seconds and then all switches except the primary switch will reboot. To see the stack configuration, do the "show stack" command. Below you will see that I ran the command when the second switch was still booting up.
FCX648SHPOE Switch#sh stack
alone: standalone, D: dynamic config, S: static config
ID Type Role Mac Address Pri State Comment
1 S FCX648SPOE alone XXXX.XXXX.6bc0 128 local None:0
. +---+
-2/2| 1 |2/1-
. +---+
Current stack management MAC is XXXX.XXXX.6bc0
FCX648SHPOE Switch#Election, was alone --> active, assigned-ID=1, total 2 units, my priority=128
Detect stack member 2 POE capable
Done hot swap: Set stack unit 2 to Ready <--- (NOTICE THE 2nd UNIT HAS BOOTED UP AND IS READY IN THE STACK)
sh stack <--- I RAN THE "SHOW STACK" COMMAND AGAIN TO SEE THE 'CURRENT' TOPOLOGY.
alone: standalone, D: dynamic config, S: static config
ID Type Role Mac Address Pri State Comment
1 S FCX648SPOE active XXXX.XXXX.6bc0 128 local Ready
2 D FCX624SPOE member XXXX.XXXX.a000 0 remote Ready
. active
. |+---+ +---+|
-2/1| 1 |2/2--2/1| 2 |2/2-
. | +---+ +---+ |
Current stack management MAC is XXXX.XXXX.6bc0
FCX648SHPOE Switch#Election, was active, no role change, assigned-ID=1, total 2 units, my priority=128
That is all you have to do. Brocade certainly makes this an easy process.
config t
stack enable
exit
stack secure
config t
stack mac XXXX.XXXX.XXXX <--- Primary switch MAC address
After the "stack secure" command, the stack will start to configure. It will take a few seconds and then all switches except the primary switch will reboot. To see the stack configuration, do the "show stack" command. Below you will see that I ran the command when the second switch was still booting up.
FCX648SHPOE Switch#sh stack
alone: standalone, D: dynamic config, S: static config
ID Type Role Mac Address Pri State Comment
1 S FCX648SPOE alone XXXX.XXXX.6bc0 128 local None:0
. +---+
-2/2| 1 |2/1-
. +---+
Current stack management MAC is XXXX.XXXX.6bc0
FCX648SHPOE Switch#Election, was alone --> active, assigned-ID=1, total 2 units, my priority=128
Detect stack member 2 POE capable
Done hot swap: Set stack unit 2 to Ready <--- (NOTICE THE 2nd UNIT HAS BOOTED UP AND IS READY IN THE STACK)
sh stack <--- I RAN THE "SHOW STACK" COMMAND AGAIN TO SEE THE 'CURRENT' TOPOLOGY.
alone: standalone, D: dynamic config, S: static config
ID Type Role Mac Address Pri State Comment
1 S FCX648SPOE active XXXX.XXXX.6bc0 128 local Ready
2 D FCX624SPOE member XXXX.XXXX.a000 0 remote Ready
. active
. |+---+ +---+|
-2/1| 1 |2/2--2/1| 2 |2/2-
. | +---+ +---+ |
Current stack management MAC is XXXX.XXXX.6bc0
FCX648SHPOE Switch#Election, was active, no role change, assigned-ID=1, total 2 units, my priority=128
That is all you have to do. Brocade certainly makes this an easy process.
Saturday, November 5, 2011
Check Point: How to setup UTM-1 high availability (step-by-step)
I came across a document I created for doing an UTM-1 install in an HA environment. I thought Id share it with you in case you ever needed help with the process. I created this so that I wouldnt forget how to do it, and its worked every time.
====================================================================
Steps to installing a HA for UTM-1
You need this info:
1. Get all IP info you need: What the VIP will be (same as the current physical IP) for DMZ, Internal, and External, etc. You also need the physical IPs for each UTM-1 (whats available that you can use, NOT for VIP).
2. You also need the management station hostname and domain name.
3. You need a screenshot of the smart update screen, for clarification.
4. You need DNS servers.
5. You need the next hop route for the default route.
6. You need any routes that are on the underlying OS, so that you can put them in on the UTM-1 system.
7. When onsite at the client, put the "upgrade_export" file on the existing Check Point box so that you can do an "upgrade_export" (to get the current config of the current system). The "upgrade_export" file has to be the same version you are going to. You can not use an "upgrade_export" from R60 when you are going to R65, etc. The location you will go to, to put the file on the existing box, is as follows: "cd $FWDIR/bin/upgrade_tools". You will need to be in expert mode. (You may want to rename the existing "upgrade_export" before you put the new one on the existing box). Then, to do the export, you type the following: "./upgrade_export". You will ftp this exported file onto your laptop so that you can take it to the lab and do an import when you are ready to do the "upgrade_import" off the UTM-1.
**NOTE**: You will need several Eval Licenses since you are going to be changing IP addresses a few times during this process. 3 should be enough to do the complete install.
Install Instructions:
1. Install the first UTM-1 with the current IP info, etc that matches the management station IP of the current install. Verify the IP address is the one of the management station that you are putting on the UTM-1.
2. After the intial install, you will reboot the UTM-1.
3. When it comes back up, you will ssh into the UTM-1. It will be time to do the "upgrade_import" for the exported file you obtained from the existing check point (cd $FWDIR/bin/upgrade_tools). You will have to ftp the exported file to the new UTM. Import will look like this example:
"[Expert@utm1570]# ./upgrade_import cpbackup.tgz"
(**NOTE**: You need to copy the file from the directory you copied to (probably /home/admin to the $FWDIR/bin/upgrade_tools folder) to do the import.
4. After the import, reboot the UTM-1 and make sure everything works. Open Dashboard up and re-IP the "old" management station to a different IP address. (**NOTE**: You may have to go into the command line and define yourself as a GUI Client (option 3) by running "cpconfig".
5. At this point, you go into the WebUI and you go to "cluster" and create the cluster. It will reboot after you create this. Its one button to push.
6. You reboot and go into smart Dashboard, and the cluster configuration automatically comes up when you log in. Cancel this. The new Cluster will be there under the check point devices now. It will only show the one primary under the cluster at this time, since you have not started on the secondary yet.
7. ***NOTE*** Ok, here I had to go back and put the original IP address back on the cluster. When it created the cluster, it made the "old" management station into the new cluster.
8. Go into WebUI, and change the IPs to what you want the primary to be, all interfaces. This wont be the VIPs.
9. Logged into Dashboard, and first thing to do is to go and pull the topology in the cluster. Go into cluster (classic mode) -->topology --> "edit topology" and "get all members' topology"
10. Put the VIPs in for the cluster. Save this.
11. Replace ALL "old" check point stations with the "new" created check point station in the policy rules.
12. Delete the "old" check point out of the configuration.
13. In order to push policy, you are going to have to get the evaluation licenses to get it to work properly. It wont push until you get them in place.
14. Goto CP User Center, and create eval licenses. Go to Smart Update and attach them. Use the IP address of the physical box, not the VIP.
15. Go into Smart Update and attach the licenses.
16. Push policy to the primary UTM-1. When it pushes, start on the secondary UTM-1.
Secondary UTM-1:
1. Install the second UTM-1 and make it the secondary in the "cluster". Go ahead and connect the crossover cable on the SYNC interface.
2. Make sure you have the license ready for the secondary.
3. Once the install is done, reboot the secondary.
4. When it comes back up, go into Dashboard, and open up the cluster. Go into simple mode (wizard) and add the cluster in Dashboard.
5. Install policy to both UTM-1s.
6. Go into smart update and add the license.
7. Make sure you have deleted out all references to the old firewall.
steps:
do the primary first
import upgrade_export
make sure it works.
configure cluster on the primary
do the secondary utm.
====================================================================
====================================================================
Steps to installing a HA for UTM-1
You need this info:
1. Get all IP info you need: What the VIP will be (same as the current physical IP) for DMZ, Internal, and External, etc. You also need the physical IPs for each UTM-1 (whats available that you can use, NOT for VIP).
2. You also need the management station hostname and domain name.
3. You need a screenshot of the smart update screen, for clarification.
4. You need DNS servers.
5. You need the next hop route for the default route.
6. You need any routes that are on the underlying OS, so that you can put them in on the UTM-1 system.
7. When onsite at the client, put the "upgrade_export" file on the existing Check Point box so that you can do an "upgrade_export" (to get the current config of the current system). The "upgrade_export" file has to be the same version you are going to. You can not use an "upgrade_export" from R60 when you are going to R65, etc. The location you will go to, to put the file on the existing box, is as follows: "cd $FWDIR/bin/upgrade_tools". You will need to be in expert mode. (You may want to rename the existing "upgrade_export" before you put the new one on the existing box). Then, to do the export, you type the following: "./upgrade_export
**NOTE**: You will need several Eval Licenses since you are going to be changing IP addresses a few times during this process. 3 should be enough to do the complete install.
Install Instructions:
1. Install the first UTM-1 with the current IP info, etc that matches the management station IP of the current install. Verify the IP address is the one of the management station that you are putting on the UTM-1.
2. After the intial install, you will reboot the UTM-1.
3. When it comes back up, you will ssh into the UTM-1. It will be time to do the "upgrade_import" for the exported file you obtained from the existing check point (cd $FWDIR/bin/upgrade_tools). You will have to ftp the exported file to the new UTM. Import will look like this example:
"[Expert@utm1570]# ./upgrade_import cpbackup.tgz"
(**NOTE**: You need to copy the file from the directory you copied to (probably /home/admin to the $FWDIR/bin/upgrade_tools folder) to do the import.
4. After the import, reboot the UTM-1 and make sure everything works. Open Dashboard up and re-IP the "old" management station to a different IP address. (**NOTE**: You may have to go into the command line and define yourself as a GUI Client (option 3) by running "cpconfig".
5. At this point, you go into the WebUI and you go to "cluster" and create the cluster. It will reboot after you create this. Its one button to push.
6. You reboot and go into smart Dashboard, and the cluster configuration automatically comes up when you log in. Cancel this. The new Cluster will be there under the check point devices now. It will only show the one primary under the cluster at this time, since you have not started on the secondary yet.
7. ***NOTE*** Ok, here I had to go back and put the original IP address back on the cluster. When it created the cluster, it made the "old" management station into the new cluster.
8. Go into WebUI, and change the IPs to what you want the primary to be, all interfaces. This wont be the VIPs.
9. Logged into Dashboard, and first thing to do is to go and pull the topology in the cluster. Go into cluster (classic mode) -->topology --> "edit topology" and "get all members' topology"
10. Put the VIPs in for the cluster. Save this.
11. Replace ALL "old" check point stations with the "new" created check point station in the policy rules.
12. Delete the "old" check point out of the configuration.
13. In order to push policy, you are going to have to get the evaluation licenses to get it to work properly. It wont push until you get them in place.
14. Goto CP User Center, and create eval licenses. Go to Smart Update and attach them. Use the IP address of the physical box, not the VIP.
15. Go into Smart Update and attach the licenses.
16. Push policy to the primary UTM-1. When it pushes, start on the secondary UTM-1.
Secondary UTM-1:
1. Install the second UTM-1 and make it the secondary in the "cluster". Go ahead and connect the crossover cable on the SYNC interface.
2. Make sure you have the license ready for the secondary.
3. Once the install is done, reboot the secondary.
4. When it comes back up, go into Dashboard, and open up the cluster. Go into simple mode (wizard) and add the cluster in Dashboard.
5. Install policy to both UTM-1s.
6. Go into smart update and add the license.
7. Make sure you have deleted out all references to the old firewall.
steps:
do the primary first
import upgrade_export
make sure it works.
configure cluster on the primary
do the secondary utm.
====================================================================
Friday, November 4, 2011
How To Upgrade The Check Point UTM-1 Via WebUI
I wanted to go over the process of doing an upgrade on the Check Point UTM-1 appliance. It used to be that the upgrade was somewhat easy, if you knew what to do. Now, its even easier with the UTM-1 appliance.
In this example today, I did an upgrade from R70.20 to R70.40. First, I had to go and download the image from Check Point's website. Just choose the appropriate image you need. In my case today, I needed Check_Point_R70.40_Upgrade.Splat.tgz. I downloaded
it, went into the WebUI, then on the left side, click 'Appliance'. In the center, click on "upload upgrade to appliance', browse to where you downloaded your image, and then upload it. It will take a few minutes to upload.
Next, you want to click on 'Start upgrade". To the right of that, it tells you the image it will use to upgrade.
The upgrade varies in time, according to the version you are upgrading to, etc. It will go through the process of decompressing the file, extracting the file, takes a snapshot of the current system config, does the upgrade, then reboots the UTM-1.
Today, the UTM-1 rebooted and I logged in and it told me that the upgrade was successful when I logged in. I could see that when I went to the 'Information' page, where it tells you the version you are running.
Now, here is the tricky thing. I have seen this one thing in the past where it used to be (and I dont know if/when this changed) that you only had a certain amount of time to do the upgrade, which you choose at the beginning of the upgrade process. If you did not log in by the time the 'timeframe you selected' was up (15 minutes was default), then it would revert back to the old version you just tried to upgrade FROM. I can say though, that the last few Check Point UTMs I have upgraded did not allow me to name an amount of time to do the upgrade in. Im not sure why sometimes its like that and sometimes its not, but you will know what it is if you see it.
So that is how you do the Check Point UTM-1 upgrade.
In this example today, I did an upgrade from R70.20 to R70.40. First, I had to go and download the image from Check Point's website. Just choose the appropriate image you need. In my case today, I needed Check_Point_R70.40_Upgrade.Splat.tgz. I downloaded
it, went into the WebUI, then on the left side, click 'Appliance'. In the center, click on "upload upgrade to appliance', browse to where you downloaded your image, and then upload it. It will take a few minutes to upload.
Next, you want to click on 'Start upgrade". To the right of that, it tells you the image it will use to upgrade.
The upgrade varies in time, according to the version you are upgrading to, etc. It will go through the process of decompressing the file, extracting the file, takes a snapshot of the current system config, does the upgrade, then reboots the UTM-1.
Today, the UTM-1 rebooted and I logged in and it told me that the upgrade was successful when I logged in. I could see that when I went to the 'Information' page, where it tells you the version you are running.
Now, here is the tricky thing. I have seen this one thing in the past where it used to be (and I dont know if/when this changed) that you only had a certain amount of time to do the upgrade, which you choose at the beginning of the upgrade process. If you did not log in by the time the 'timeframe you selected' was up (15 minutes was default), then it would revert back to the old version you just tried to upgrade FROM. I can say though, that the last few Check Point UTMs I have upgraded did not allow me to name an amount of time to do the upgrade in. Im not sure why sometimes its like that and sometimes its not, but you will know what it is if you see it.
So that is how you do the Check Point UTM-1 upgrade.
Wednesday, November 2, 2011
Check Point R75.20 boot issue after upgrade to R75.20
Not long ago, a friend and I were upgrading a CP management station in a distributed environment. He has a Smart1 appliance running initially R75, upgraded to R75.10. The two enforcement modules (clustered together) were running R75 as well, and again upgraded to R75.10. We decided, for a few reasons, to upgrade to R75.20. We upgraded only the management station, and had planned on upgrading the enforcement modules later on. But, we ran into a problem that needs to be discussed.
While in the WebUI on the management station, we did the upgrade from there. Upgrade took a little time, and then a reboot. When the reboot happened, it never came up. We went down to the datacenter and consoled into the box and sure enough, it was hanging up. So, we searched on a check point forum and found that one guy had actually run into this. Check Point didnt know what to do with this either, and while we were in somewhat of panic mode, we found this guys post and tried it out.
While consoled in, we booted up in maintenance mode. That means stopping the normal boot process and pressing "any key" to go into the menu options. Select "maintenance mode" and let it boot from there, which it did. Then the forum told us to edit the file /boot/grub/grub.conf . That meant to me using VI Editor, which I am almost clueless to. However, I did know enough to do the job. This file was missing 2 lines :
This is a small secction of what the file looked like AFTER THE UPGRADE, and BEFORE I EDITED IT:
------EXTRACT /boot/grub/grub.conf BEFORE-------
password --md5
splashimage=(hd0,0)/grub/splash.xpm.gz
kernel /vmlinuz ro root=/dev/mapper/vg_splat-lv_current vmalloc=256M p
anic=15 console=SERIAL 3 quiet
initrd /initrd
title Start in maintenance mode
lock
root (hd0,0)
------------------------------------------------
With what you see above, it wouldnt start in "Normal mode". So, below is what I had to do to get this going. I did the "vi /boot/grub/grub.conf" command, it opened the file, arrowed down under the "splashimage=....." line, and pressed "i" to insert characters. I put the next two lines in: "title Start in normal mode" and "root (hd0,0)". See below.
------EXTRACT /boot/grub/grub.conf AFTER-------
password --md5
splashimage=(hd0,0)/grub/splash.xpm.gz
title Start in normal mode
root (hd0,0)
kernel /vmlinuz ro root=/dev/mapper/vg_splat-lv_current vmalloc=256M p
anic=15 console=SERIAL 3 quiet
initrd /initrd
title Start in maintenance mode
lock
root (hd0,0)
------------------------------------------------
To finally get out of VI, I hit the "ESC" key, then ":wq". Im not sure what the colon means, but w means write (to save) and q means quit.
Then, I rebooted the management station and it came up with R75.20 just fine.
Funny enough, when we did upgrade the enforcement modules later on, we had to do the same thing on both of them. I still dont know why and Check Point TAC didnt seem to know either. Either way, fixed and upgraded.
While in the WebUI on the management station, we did the upgrade from there. Upgrade took a little time, and then a reboot. When the reboot happened, it never came up. We went down to the datacenter and consoled into the box and sure enough, it was hanging up. So, we searched on a check point forum and found that one guy had actually run into this. Check Point didnt know what to do with this either, and while we were in somewhat of panic mode, we found this guys post and tried it out.
While consoled in, we booted up in maintenance mode. That means stopping the normal boot process and pressing "any key" to go into the menu options. Select "maintenance mode" and let it boot from there, which it did. Then the forum told us to edit the file /boot/grub/grub.conf . That meant to me using VI Editor, which I am almost clueless to. However, I did know enough to do the job. This file was missing 2 lines :
This is a small secction of what the file looked like AFTER THE UPGRADE, and BEFORE I EDITED IT:
------EXTRACT /boot/grub/grub.conf BEFORE-------
password --md5
splashimage=(hd0,0)/grub/splash.xpm.gz
kernel /vmlinuz ro root=/dev/mapper/vg_splat-lv_current vmalloc=256M p
anic=15 console=SERIAL 3 quiet
initrd /initrd
title Start in maintenance mode
lock
root (hd0,0)
------------------------------------------------
With what you see above, it wouldnt start in "Normal mode". So, below is what I had to do to get this going. I did the "vi /boot/grub/grub.conf" command, it opened the file, arrowed down under the "splashimage=....." line, and pressed "i" to insert characters. I put the next two lines in: "title Start in normal mode" and "root (hd0,0)". See below.
password --md5
splashimage=(hd0,0)/grub/splash.xpm.gz
title Start in normal mode
root (hd0,0)
kernel /vmlinuz ro root=/dev/mapper/vg_splat-lv_current vmalloc=256M p
anic=15 console=SERIAL 3 quiet
initrd /initrd
title Start in maintenance mode
lock
root (hd0,0)
------------------------------------------------
To finally get out of VI, I hit the "ESC" key, then ":wq". Im not sure what the colon means, but w means write (to save) and q means quit.
Then, I rebooted the management station and it came up with R75.20 just fine.
Funny enough, when we did upgrade the enforcement modules later on, we had to do the same thing on both of them. I still dont know why and Check Point TAC didnt seem to know either. Either way, fixed and upgraded.
Check Point Blocking H323 Traffic
A funny thing I learned today about Check Point. Here is the scenario: I have a remote-access client wanting to vpn into my check point clustered environment. Im running R75.20. Remote-access works great. I can get to everything, except I can not get my Avaya softclient to register to the IPT server inside the network from across the remote-access vpn. I start the client up, and try to log in, and it times out. Seems really odd, since I CAN ping this server and telnet to it. So, routing is out. No route-maps in the network that would send protocol specific traffic elsewhere. What gives? First, know that I had a rule specifying that vpn users could get to anything, with any service allowed. The IPT server was in the encryption domain as well. Everything looks good in the config.
So, I call Check Point TAC up, and after some time in looking at this, they tell me to add another rule specifically allowing the H323 traffic Im trying to get across with the Avaya client. I tell them I have a rule already allowing "any" traffic through. Essentially, they tell me to just do it. So, I did add a rule in to allow H323 traffic through and back. I saved and pushed policy and it the Avaya client worked. Hmmm. I have no idea why this worked. But, I did. I had another guy tell me at this customer site that he has seen this sort of thing before. When I ask why, his answer was "Its check point."
So, this got fixed by adding another rule in the rule base for a protocol (H323) that was already allowed anyway. This is one of those scenarios where I just have to shake my head and say "I dont know."
So, I call Check Point TAC up, and after some time in looking at this, they tell me to add another rule specifically allowing the H323 traffic Im trying to get across with the Avaya client. I tell them I have a rule already allowing "any" traffic through. Essentially, they tell me to just do it. So, I did add a rule in to allow H323 traffic through and back. I saved and pushed policy and it the Avaya client worked. Hmmm. I have no idea why this worked. But, I did. I had another guy tell me at this customer site that he has seen this sort of thing before. When I ask why, his answer was "Its check point."
So, this got fixed by adding another rule in the rule base for a protocol (H323) that was already allowed anyway. This is one of those scenarios where I just have to shake my head and say "I dont know."
Subscribe to:
Posts (Atom)