|
|
|
|||
|
|
||||
If you can't find what you need here, try a different FW-1 Version
GENERAL
1) I get "Authentication Failed" when trying to
log into the GUI.
2) CPD port (18191) is not listening
3) fwd or vpnd process will not start
4) Branch offices cannot get to some web sites
INSTALL
1) How do I upgrade to NG?
2) Where is my configuration kept (what should I back up?)
3) "data is invalid" when I try to save a policy
4) "Failed to pass version to kernel"
5) "Failed to Load ... psapi.dll" when
installing foundation
6) After I upgrade and reboot, I can no longer
talk to my firewall because of the defaultfilter.
7) "Failed to load on module - no
memory"
LDAP
1) How do I setup Active Directory authentication?
LOGGING
1) How do I change the log directory?
DISTRIBUTED MANAGEMENT
1) How do I do putkeys?
2) I boned SIC and need to reinitialize the
Management Station.
3) I want to remotely manage a firewall I accidentally
installed a Management Station on.
4) "SIC error no. 148"
NAT
1) How does Static Destination mode NAT work?
2) NAT works for ICMP, but not TCP/UDP traffic.
PROXIES/CVP/AUTHENTICATION
1) Partial Client Authentication fails.
2) How do I do implicit client authentication (one CA rule
triggers all rules)?
3) "Connection restricted by http_connection_method_proxy"
RULE BASE
1) Invalid Service in rule XX.
2) "<obj> conflicts with <obj>"
during install.
3) Installing policy is very slow on Windows 2000
4) How do I view the rules/objects without being
on a Management station?
5) Installing a policy, I get "changes
could not be saved"
6) "Target localhost is not defined as an NG module, please use the -l flag"
when installing policy.
ENCRYPTION
1) I get "failure in SSL protocol"
error.
2) I keep getting "invalid subnet"
when building an IKE tunnel
3) How do I set up L2TP W2K clients (FP3)?
4) I upgraded from 4.1. What DH groups do
I use now?
5) Give me some tips for VPNs to Cisco devices.
6) vpnd process takes 100% of CPU
SECUREMOTE
1) How do I force SecuRemote to NOT check the
CRL for certificate authentication?
2) "site <IP> is configured to transmit topology data without authentication"
3) SR authenticates ok, but does not encrypt (icon
does not flash)
4) "You are not licensed to obtain a security policy"
5) "No pre-shared secret defined for user"
SECUREPLATFORM
1) How do I upgrade SP?
2) No link lights appear on NIC
3) How do I install/uninstall packages?
4) "Logout: Already Connected" error when
trying to connect to web interface
5) How do I up the timeout on my login?
6) How do I enable DHCP server or Relay?
HIGH AVAILABILITY
1) Error "Check on member X (1.1.1.1) detected
a problem (3 interfaces > required, only 2 up)"
There are a number of reasons this error comes up:
NG has some flakiness (FP2). You may see "disconnected" in the status viewer, or get "SIC status ... unknown". Nokia and floodgate can cause this, and I have seen a Management station with SecurePlatform do this. Recommendation: don't use these combinations of products.
A number of things can cause this. Check the following:
0 vpn vpnd respawn 0
0 dtps dtpsd respawn 0
There are a number of reasons this may happen, but one issue may
be if the traffic to your branch sites is encapsulated via a VPN or
other tunnel. Encapsulated traffic requires additional packet
information to create the tunnel. Often, tunnel types such as
Cisco's GRE tunneling will set a lower MTU on transmitted data to
make the data fit in the tunnel. So a standard ethernet
segment might be 1500 bytes / packet, but the Maximum Transmission
Unit size would be set to 1452 or less such that 40 or so bytes can
be slapped on to your packet by encapsulation, and the final packet
would not exceed the physical segment's 1500 bytes.
Why is this bad? Well, if the tunnel only allows
1452 byte packets, packets bigger than that must be
fragmented. However, TCP traffic often has the DF (do not
fragment) bit set. Ordinarily, if a packet is too big for the
MTU, the constricting router will send an ICMP type 3 code 4
destination unreachable packet to the server, meaning "fragmentation
needed and DF set". The server would then send smaller
packets. However, the ICMP may never reach the server, or the
server may ignore it, etc. In any case, the large web page
data packets will cause the web request to hang and fail.
There are a number of suggested
solutions:
interface eth0 ip policy route-map clear-df route-map clear-df permit 10 match ip address 111 set ip df 0 access-list 111 permit tcp 10.1.1.0 0.0.0.255 any
interface tunnel1 ip tcp adjust-mss 1412
If you are on version 4.0 and earlier, upgrade to v4.1 first. This is recommended in FP1, but will be required in FP2. From there, you have 2 options: your best bet is to:
Alternatively, you can try:
I haven't tried that last one!!!
$FWDIR/conf, just like version 4.x. However, some global properties (like your licenses) are now stored under $CPSHARED/conf.
Something is corrupt, obviously. One possible cause of this is you upgraded from 4.1 to NG and didn't remove the 4.1 environmental variables from your path.
(Solaris) When you applied patches (eg, FP2) to a base install, you may have done a "pkgadd." Use "patchadd" instead.
When installing FP3 on Windows NT, you get this error. Install CPshared FP1, THEN FP3 foundation (you don't need FP1 FW-1 installed).
You can get a remote console connection (dial-up or call someone on site) and type "fw unloadlocal". This will disable the default policy. If you do NOT have remote console access, you can modify the defaultfilter.pf file manually. On the firewall (before the reboot, but after the software upgrade), edit $FWDIR/conf/defaultfilter.pf (might want to make a backup first). Add the following below "drop (inbound....":
all@all
accept inbound, tcp,
<[16]> in host_ip_addrs,
dport = 23,
DEFAULT_RECORD();
Which would allow telnet to the firewall. Obviously you can modify to your needs. Then go ahead and reboot.
Often times this is caused by 2 firewall modules that have the same IP address. Make sure your firewalls have unique IPs if they are not cluster members.
delegrate control of AD tree
1) AD users and Computers
2) right click domain and choose delegate control
3) add user who can control AD and reboot
view AD schema
1) regsvr32 schmmgmt.dll
2) mmc
3) add snap in "Active Directory Schema"
4) right click AD Schema and choose "Operations Master", and check
property "Schema may be modified on this DC" & set full
permissions for your AD admin account
Activate SSL Communications
1) add certificate services software
2) administrative tools > domain security policy > security settings >
public key policies
3) in the right pane, right click "Automatic cert request settings"
and select "new automatic cert req"
4) select DC from the templates list. SSL is now enabled
extend AD schema (SmartCenter Server)
1) edit $FWDIR/lib/ldap/schema_microsoft_ad.ldif
2) replace all "DOMAINNAME" with domainname of your org (eg: "DC=company,DC=com")
3) ldapmodify -c -h <DC ip> -D "cn=<admin>,DC=company,DC=com"
-w <admin password> -f schema_microsoft_ad.ldif
Rule Base
1) create an Account Unit object
-Account Usage: CRL & User Management
-LDAP server profile: Microsoft_AD
-Servers Tab:
add server:
host: object for AD server
port: 389
Login DN: cn=<admin>,cn=users,DC=company,DC=com
password: admin password
Early Version Compatibility Server: <server you just created>
-Encryption:
use SSL: enable
min/max: strong
-objects management tab:
fetch branch(es)
-authentication tab:
Default Auth Scheme: FW1 password
2) go to "users" tab in objects tree
3) double click the created Account Unit object, and then double click
"users" to fetch user accounts from LDAP
4) You can now create "LDAP groups" and use these groups in rules
Add the following registry entry:
HKLM\Software\Checkpoint\FW1\5.0\FWLOGDIR
and set the value to the path where you want logs sent. Reboot.
If you are on a UNIX machine, just use symbolic links.
Basically, you don't anymore. Putkeys exist for backward compatibility only. You need to establish SIC (Secure Internal Communications) which utilize digital certificates. To do this, you must:
If you wish to reset the connection, you must repeat steps 2 and 3 (although 2 does not require a reinstall; merely use cpconfig to reinitialize the module).
First, you must be on the management console. Type:
fw sic_reset
This will wipe your internal CA and stop the firewall. Next, run "cpconfig" and reinitialize your internal CA. Finally, restart the firewall (cpstart), and log in. Your GUI should ask you to verify a new fingerprint.
Warning: you may get the error:
*** Checking IKE Certificates ***
There are IKE Certificates that were generated by the
internal Certificate Authority.
Please remove them (using the Policy Editor) so that
the internal Certificate Authority can be destroyed.
SIC Reset operation could not be completed
This indicates an object(s), most likely your firewall, has an IKE cert under the VPN tab. You must delete this cert to continue. If you can't get into the GUI because the cert is boned, you must edit $FWDIR/conf/objects_5_0.C after stopping the firewall and edit your firewall object. You will see a "certificates" subsection that looks like:
:certificates (
: (demone-auth
:AdminInfo (
:chkpf_uid ("{8AD40154-F442-433D-B561-14D7AC7657E2}")
:ClassName (certificate)
)
:"#certreq-pki-gen" (false)
:"#pki-host-cert-set" (false)
:ca (ReferenceObject
:Name (SecevRoot)
:Table (servers)
:Uid ("{29DF35A6-D330-4D75-B2BE-A1FE45E4B0BB}")
)
:dn ("CN=Administrator,Email=Administrator@company.com")
:pkisignkey (176eac6c923f71adc618ee98)
:status (signed)
:stored.at (management_server)
)
Modify this so it looks like:
:certificates ()
and start your firewall. Try "fw sic_reset" again.
This is a bit tricky. 4.1 actually handled this much better. The best thing to do is reload and start from scratch, but if you absolutely can't, then do the following:
This SIC error indicates there is a timeout issue talking to your firewall. Check your connectivity to the firewall, and make sure your fwd process is running and responsive. Also check firewall system resources. If CPU is spiked, for example, fwd may slow down enough to cause this error.
Static NAT no longer requires spoof changes/ARPs/and routing modifications. All you need to do is build the NAT rule in the GUI. However, in order to make sure this works properly, go to "Global Properties", "NAT" tab, and make sure the following are checked:
We have noticed a bug in Rapidstream (FP3)
boxes where NAT & acceleration do not work together. ICMP
works fine, but TCP & UDP connections fail. A common error
that pops up is "connection contains real IP of nated
address". Check Point KB suggests this is due to the
existence of multiple XL Clusters on the same VLAN. This may
be the case, and as a matter of fact, the customer was trying to get
2 virtual IPs on the same NIC.
In any case, the ultimate fix was to turn off SecureXL
acceleration ("fwaccel off"). This sucks if you
spent all that $$ on a RAPIDstream, but hopefully a fix is
coming.
There are lots of potential causes here, but one thing you should make sure exists is a user authentication rule that mirrors the client authentication rule. Client authentication CANNOT hand off to user authentication if there is no security server running. So for example:
| Source | Destination | Service | Action |
| AuthUsers@ext_net | int_net | http icmp ... |
ClientAuth |
| AuthUsers@ext_net | dummyserver | http | UserAuth |
Couple of things: first, make sure the "Source" IP addresses match. That is, if client authentication is allowed from "ext_net" then user auth must be allowed from the same location (otherwise the Security Server might not kick off). Notice the destination can be arbitrary, however. You do NOT need to allow user authentication to the same destination, or even a real destination. All the rulle needs to do is kick off the Security Server.
1) Create multiple client auth rules as you normally would.
2) On the firewall, edit $FWDIR/conf/objects_5_0.C (MAKE A BACKUP OF THIS FILE FIRST!!!!!!!!)
3) Edit the line in the firewall object:
:automatically_open_ca_rules(false)
and change it to:
:automatically_open_ca_rules(true)
this will cause ALL client auth rules to activate when you hit ONE client auth rule.
4) Reinstall your policy
If you are trying to use an HTTP Security Server to allow/disallow your web traffic, you might get the above error in your logs, even though the proxy is correctly configured. There are 3 transport mechanisms for HTTP: transparent, proxy, and tunnel. In order to use any of the 3, the methods must be enabled in your Global Properties. If you are trying to proxy your web browser to the firewall, you would use: http_connection_method_proxy. If you are using a tunneling protocol (like HTTPS), you need http_connection_method_tunneling. These methods are defined in $FWDIR/conf/objects_5_0.C:
:http_connection_method_proxy (false)
:http_connection_method_transparent (true)
:http_connection_method_tunneling (false)
You must convert any method you wish to use to (true). This can be done by editing the objects file, or more safely (with R55) by going to "Global Properties > SmartDashboard Customization > Advanced Configuration > FireWall-1 > Web Security > HTTP Protocol. Check the methods you wish to use.
Check comments of the rule. Eg, if the service is "ftp", the comment cannot be "ftp", but "ftp rule" will work fine. Change or erase the comment field (FP1).
NG (FP1) will not let you have two services with the same port, and will tell you this on install. However, if you have a service (say, 6011) which overlaps with a PORT RANGE (say 6000-6060), the firewall will tell you <service> conflicts with <service> because port range objects obviously freak it out (FP1).
Win2000
has a pseudo-interface called NDISWANIP. If you do not define
this in the firewall's interfaces (firewall object, topology tab),
installation is slow. workaround is to define it and give it a
fake address and spoof definition.
Also, make sure your Management station and firewall are in
the hosts file. Firewall will attempt a DNS resolution, and if
it can't find its own name, installation will be slow.
Issue seems to be resolved in FP2.
FP0/1: Copy the following files from $FWDIR/conf to the Program directory of the GUI (usually c:\program files\checkpoint\management clients\5.0\program):
| File | Rename to: | Purpose |
| rulebases_5_0.fws | rules.fws | FW1 rules |
| objects_5_0.fws | objects.fws | objects |
| Setup.C | setup.fws | default settings (optional) |
| fgrulebases_5_0.fws | fgrules.fws | Floodgate (QoS) rules |
| lcrulebases_5_0.fws | cerules.fws | Log Consolidator rules |
| slprulebases_5_0.fws | slprules.fws | SecureClient desktop rules |
FP2+: Copy the above files to your GUI directory (usually c:\program files\checkpoint\management clients\NG FP#\program\cpml_dir\conf). Do NOT RENAME any files! (thanks to martin for pointing this out; even the FP2 training guide has this listed incorrectly)
Then, log into the GUI policy editor with any username/password, and for management station, use "*local", or "Demo Mode."
Your policy has become corrupted. Go to "File\Save As" and
save your policy as a new name. Then install the freshly named policy.
The other possibility is you are out of disk space.
You have defined multiple objects with the same IP as the management station.
You are trying to SSL encrypt to a station that has an unsynced clock. Either your cert is not valid according to their clock or visa versa. Sync clocks and regenerate both certs.
Often when connecting to non-Check Point products (Cisco), I get invalid subnet errors even though I double checked encryption domains on both sides. Check Point will supernet multiple networks of an encryption domain together if possible. 2 class Cs will be joined into a single /23 and transmitted to a peer that expects class C networks. Either manually supernet your encryption domain networks, or set "ike_use_largest_possible_subnets" to false in objects_5_0.C.
(see www.phoneboy.com for full article) Ensure that Office Mode is set up. Additionally, make sure that the L2TP-specific options are configured accordingly. If MD5 Challenge is used, make sure that users that will be using MD5 Challenge are configured with IKE Pre-Shared secrets. The IKE Pre-Shared secret will be the password the user enters when prompted by the client. In your rulebase, ensure that the L2TP service is permitted to the firewall.
Each machine requires it’s own certificate. The Check Point documentation is unclear how one goes about creating a certificate for these machines, though it seems to suggest two different users be created - one for the machine and one for the user. In practice, you only need one user and one certificate, though you end up needing to install it in two different locations if you use certificate-based authentication, only one with MD5 Challenge.
Before any client certificates are issued, an adjustment needs to be made to how FireWall-1 generates certificates. This is necessary, as Windows require that specific attributes be set in the certificates, and FireWall-1 does not set these by default. On the management console, if using the Internal CA to generate L2TP certificates, perform the following steps:
1 Type cpstop.
2 Edit $FWDIR/conf/InternalCA.C and add the following lines:
:ike_cert_extended_key_usage (1)
:user_cert_extended_key_usage (2)
The first line tells the Internal CA to generate IKE certificates for gateways with the “server authentication” purpose. The second line says to generate user-certificates with the “client authentication” purpose.
3 Type cpstart.
If you’re using an OPSEC CA instead, log into the management station with dbedit (or use GUIdbedit) and issue the following commands:
dbedit> modify properties firewall_properties cert_req_ext_key_usage 1
dbedit> update properties firewall_properties
Now restart the management console with cprestart.
Client certificates can be issued with the correct attributes. Go into the appropriate user(s), generate and save the certificate to your local system. You will then have to somehow give the certificate and the associated passphrase to the end user. The end user will then install this certificate into their platform. To install the certificate into Windows 2000 and XP:
1 Log into the desired platform as a user with local administrator privileges.
2 Copy the certificate onto the desired platform into a known location. For the purposes of these steps, we will assume the certificate file is copied to the path c:\data\fish.p12.
3 From the command prompt, or from File, Run, run the command mmc, i.e. the Microsoft Management Console.
4 From the console menu, select Add/Remove Snap-in.
5 In the “Add/Remove Snap-in” window, click on Add.
6 In the “Add Standalone Snap-in” window, select Certificates and click on Add.
7 In the “Certificates Snap-in” window, select “Computer Account” and click on Next.
8 In the “Select Computer” window, select “Local Computer” and click on the Finish button. If you are using MD5 Challenge for authentication, skip to step 11.
9 In the “Add/Remove Snap-in” window, click on Add.
10 In the “Add Standalone Snap-in” window, select “My user account” and click on Finish.
11 Click on Close in the “Add Standalone Snap-in” window
12 Click on Close in the “Add/Remove Snap-in” window.
13 Double-click on “Certificates (Local Computer)” and you will see a list of certificate types in the “Logical Store Name” frame.
14 Double-click on “Personal” in the “Logical Store Name” frame. That frame should be replaced with one called “Object Type.”
15 Right-click in the “Object Type” frame and select “All Tasks,” then “Import.”
16 Click on “Next” in the resulting “Certificate Import Wizard” screen.
17 Specify the path to the certificate file, which in this case is c:\data\fish.p12
18 In the next screen, type in the passphrase used by the administrator to protect the certificate. Check the “Mark Private Key as Exportable” checkbox. Click on Next.
19 When prompted for a certificate store, select “Automatically…” then click on Next, then Finish. Click on “Ok” in the dialog that notifies you the import was successful. If you are using MD5 Challenge for authentication, skip to step 22.
20 Double-click on “Certificates - Current User” and you will see a list of certificate types in the “Logical Store Name” frame.
21 Repeat steps 14 thru 19.
22 From the “Console” menu, select “Save.”
23 Specify a file with a .msc extension, e.g. Console1.msc. Click Save.
24 Exit the Microsoft Management Client.
The client will now have the ability to utilize the certificate for authenticating the L2TP session. The next step is to ensure the “IPSec policy agent” is running, which can easily be checked by typing the command net start “IPSEC Policy Agent” into a command prompt and see if it says it is already started. If it is, chances are its enabled by default as well. If this command starts up the IPSEC Policy Agent, you will need to go into the Services (under the Administrative Tools section of the Control Panel) and set the IPSEC Policy Agent to start automatically.
On the client:
1 Create a "new dialup connection" on W2K
2 Choose “Connect to a private network through the Internet”
3 Choose whether or not to dial-up an initial connection. You would do this if you needed to use dial-up to establish an Internet connection.
4 Enter the gateway’s DNS resolvable name or IP address
5 Enter a name for this connection and click on Finish.
6 Right-click on the connection icon just created and select “Properties.”
7 Click on the Networking tab. Specify the VPN server type as L2TP.
8 Click on the Security tab, choose “Advanced” security options and click on “Settings.”
9 Under “Logon Security,” select “Use Extensible Authentication Protocol (EAP).” Under the pulldown, select Certificate or MD5 Challenge depending on what was specified on the gateway.
10 If certificates was chosen, click on Properties and certificate. Uncheck “Validate Server Certificate” unless you wish to export the Internal CA key and import it into the workstation. Click Ok.
11 Click “Ok” twice.
Now your client should be able to connect using this new network connection profile. When it is activated, you will either enter your username and IKE pre-shared secret or select your certificate and click Ok. Assuming everything was configured correctly, the connection should come up.
By default, 4.1 used DH group 1 in phase 1 and you are not given a choice. If you are maintaining an existing tunnel, keep this setting.
This may be a result of cached file corruption. You may want to first take a look at $FWDIR/log/vpnd.elg, and see if there are any noticeable errors. If not, perhaps try putting the vpn daemon in debug mode: "vpn debug on" to see if any additional info gets logged to vpnd.elg. If none of this helps, try deleting files in the $FWDIR/database directory on the firewall. An obvious culprit for vpnd is crlcache.NDB* (may want to just move them to a different directory), and then restart the firewall. More generally, you can delete everything in the database directory (shotgun approach), although you may have to reset SIC at that point.
Edit the userc.C file and change the line:
:sr_dont_check_crl (false)
to (true). This line is near the bottom under "managers" section. You will have to fetch topology before the line appears.
You upgraded from 4.1 or NG FP1 to FP2+ and are trying to use unauthenticated topology requests. This is no longer supported. Set the "allow_clear_gettopo" property in objects_5_0.C to false (dbedit is recommended).
First, check to make sure you are sucking down a topology. On the client, check the <SR directory>\database\userc.c file, and make sure there is a gws: section with your encryption domain defined within it, something like:
:gws (
...
:topology (
:(
:name (65.1.1.1.firewall)
:type (network)
:ipaddr (172.16.0.0)
:ipmask (255.255.0.0)
)
....
You also might want to make sure the topology is correct, and you don't have any "0.0.0.0" networks. If topology is incorrect, fix you firewall object's "topology" tab.
The user ID you authenticated with is not in the SecureClient user group.
The first thing to check is make sure the user has a
pre-shared secret defined in his/her user definition. Go to
the user object, and click encryption tab. Edit
"IKE" properties, and check and add a password.
If you are using LDAP instead of local accounts, you can get
this error if the user is not found. Make sure you are using a
valid LDAP userid, and that FW1 can see that account. You can
view LDAP userids by clicking the user tab in the Objects Tree, and
then double-clicking the relevant LDAP account unit. If you
double-click on sub branches, the user IDs will appear in the
Objects List.
You can use SecureUpdate, but if you don't
have the license, you can use "patch add" in a
pinch. Make sure the CD for the new version is in the
drive. From the command line, type "patch add cd"
(this works for FP3+, if you are on FP2, you must upgrade
"patch" command by mounting the cdrom, "mount /mnt/cdrom",
then patching "patch" with the full path: "patch
add /mnt/cdrom/SecurePlatform/patch/CPpatch_command.tgz" ).
However, that step will ONLY upgrade the OS, NOT the
firewall. Next, you must add the firewall packages with the
rpm command. Make sure the CD is mounted. In the RPMS
directory (usually /mnt/cdrom/SecurePlatform/RPMS), run:
rpm -i CPshrd-50-03.i386.rpm
rpm -i CPfw1-50-03.i386.rpm
Obviously, you would update to whatever version you are migrating. This example is for an upgrade to FP3.
Certain cards do not autodetect well on SecurePlatform, eg: tulip.o driver cards with DEC 2114x chipsets. If the tulip driver is not working for you, try de4x5. Edit the /etc/modules.conf file and change
alias eth0 tulip
to:
alias eth0 de4x5 options de4x5 args='eth0:fdx eth1:autosense=10Mb'
or some such. We have found that the 10/100 thing causes issues, so if you need 10Mb, specify as above.
I am guessing at some point they will integrate this into the GUI, but for now, use "rpm -e <pkg>" to uninstall, "rpm -i <pkg>" to install, and "rpm -qa" to query all existing packages. <pkg> would look something like "CPfw1-R55-00.i386.rpm". When installing, use the FULL name (including .rpm), and when uninstalling, do NOT use full name, but rather something like "CPfw1-R55-00" without the .rpm or even the .i386 architecture. Clear as mud?
(R55) Not sure why this happens, but apparently the web daemon becomes confused and needs to be restarted.
Usually means someone else is connected and didn't disconnect. For whatever reason, R55 does NOT auto-logout after a time period. Solution: disable and re-enable the Web User Interface. Log on command-line (ssh or console), and in expert mode:
webui disable webui enable
If that doesn't work, try to restart the web processes manually:
cpwmd cp_http_server
Use the "idle" command, such as "idle <seconds>".
Log in to Secure Platform command line and run
"sysconfig" command. This will bring up a
menu. To configure SPLAT as a DHCP server, go to the DHCP
server section and create the relevant DHCP range of
addresses. The range must be on a directly connected interface
(which could be a physical interface or a VLAN). The DNS
server is assigned by whatever DNS server SPLAT is using, so you
can't make individual scope assignments.
If you wish to use an internal or DMZ DHCP server, go
to the DHCP relay option. You must specify the DHCP server IP,
and then specify what interfaces you wish to relay for. Make
sure you specify BOTH the source and destination interfaces of the
DHCP traffic. If you are using VLANs, specify at LEAST the
VLAN interface (eg: eth0:VLAN) and the physical interface associated
with the VLAN (eth0) AND the interface you are relaying TO (eg:
eth1). Changes will be saved automatically, but make sure you
say yes when exiting the menu and are prompted to restart the DHCP
server.
(R55) There are often issues with multicast on certain switches (Cisco). By default, most HA schemes such as New Mode HA and Load Sharing (NOT Legacy HA) use multicast traffic to communicate with peers. Some switches get confused by this, causing the above errors. Consequently, you will see the above error over and over again in the logs every few seconds. In SMARTview Status viewer, you will occasionally see "Problem" status with a cluster member, and then it will clear up by itself. Strangely enough, clustering still works for some reason, but the errors are annoying.
Solution: you CAN get rid of your switches and replace them with different brands, or perhaps hubs, but the easiest way to fix is to convert the communications on the interface from multicast to broadcast. To do this, log in to the cluster member command line. First determine what mode the interfaces are in:
cphaprob -a if
The interfaces should be listed as well as whether or not they are (state) sync interfaces, UP or DOWN status, and multicast vs broadcast status. If one or more interfaces are listed as multicast, type:
cphaconf set_ccp broadcast
This will set ALL interfaces to broadcast, and stop the extraneous logging. If you need to set them back to multicast, type the previous command, and substitute "multicast" for "broadcast".
Home | Services | Training | Support | Contact Us | Search
Copyright 2006, Security Evolution, Inc.