Exclude CPM Traffic from Implied Rules

[Paul_Warnagiris]

My question is similar to this thread Exclude CPM traffic from implied rules  however I have a 77.30 GW on-prem with a VPN to an R80.10 AWS vSec instance.  Both are managed by different managers.  So when the traffic is initiated from my management client behind the 77.30 GW, it encrypts.  When it gets to the 80.10 GW it "accepts" and doesn't decrypt.  So I followed the thread above where I commented out ENABLE_CPMI, but no change.  Encrypt on the on-prem side (I did not change anything there) and accept on rule zero at AWS.  

Here is my implied_rules.def

[Expert@bi-prod-fw:0]# cat implied_rules.def | grep CPM

/* #define ENABLE_CPMI */

#ifdef ENABLE_CPMI

                (dport = CPMI_PORT or dport = CPMI_PORT_NGM), tcp,                                                                                              \

                (sport = CPMI_PORT or sport = CPMI_PORT_NGM), tcp,                                                                                              \

[Expert@bi-prod-fw:0]#

Am I missing something simple?  The customer really does not want to manage this through the Internet even though I believe that the best way to go.

Thanks,
Paul

[Vladimir · Accepted solution]

May be I am reading the thread you are referencing wrong, but it looks to me that the implied_rules.def file should be edited on the management server, not the gateway.

Since the object you are managing is called bi-prod-fw:0 , I'm inclined to think that it is a gateway.

The sk111954 dealing with logging through the VPN, which relies on subset of CPMI indicates same approach:

Symptoms

• Logs from Security Gateway do not arrive to Log Server through VPN Tunnel. Example Topology:
  MDS (CMA)---[SGW1] ==== VPN Tunnel==== [SGW2]---MLM log server
• From Security Gateway 1, telnet/ping to the Log Server is working.
• From Security Gateway 1, telnet to port 257 of the Log Server is not working.
  fw monitor on Security Gateway 1 is showing that the traffic does not pass through VPN:
  
  vpnt1:o[60]: [SGW1 IP] -> [log server IP] (TCP) len=60
  eth2:O[60]: [SGW1 IP] -> [log server IP] (TCP) len=60

Cause

By design, when "Accept control connections" is enabled, The Security Firewall log connection to the Log Server will be matched by the Security Gateway on the implied Rules instead of the VPN configuration and rulebase.

Solution

1. Close all SmartConsole windows.
2. Connect to the command line on the Security Management Server.
3. Log in to Expert mode.
4. Backup the relevant implied_rules.def file. Refer to sk92281 for the location of 'implied_rules.def' files on Security Management Server/Domain Management Server.
5. Edit the relevant implied_rules.def
6. Find and Comment out the "#define ENABLE_FWD_LOG" line
   • Change from:
     
     #define ENABLE_FW1_SAM
#define ENABLE_FWD_LOG
#define ENABLE_IKE
     
     To:
     
     #define ENABLE_FW1_SAM
/* #define ENABLE_FWD_LOG */
#define ENABLE_IKE
     
     
7. Save the change and exit from the editor.
8. Connect with SmartDashboard to the Security Management Server/Domain Management Server.
9. Make sure the VPN policy allows traffic on TCP port 257.
10. Install policy to the Security Gateway.

[Paul_Warnagiris]

Great call.  That worked.  Now I'm getting CRLs failed to be downloaded and now I see rule zero for FW1_ica_services.  I assume comment out #define ENABLE_FW1_ICA_SERVICES

Thoughts?

[Paul_Warnagiris]

That worked.  Thanks so much for your input!!!

[Vladimir]

Glad to be of help

Please mark the question as answered, so the others in similar situation could use this for references.

Cheers,

Vladimir

[PhoneBoy]

As a general rule, it is a bad idea to force control connections through the VPN.

If your VPN goes down for any reason, getting it back up when you have no ability to manage the gateway becomes a challenge.

[Paul_Warnagiris]

Agree.  I made them aware of that.  They are leaving external access there, just not leaving it open.  Thats the break-glass-in-case-of-emergency access method.

Thanks,
Paul