More frequently, than expected, CheckPoint LOM cards stop responding to HTTPS connections, or even to pings. This is how they can be reset from GAIA CLI:
service ipmi start ipmitool mc reset cold service ipmi stop
More frequently, than expected, CheckPoint LOM cards stop responding to HTTPS connections, or even to pings. This is how they can be reset from GAIA CLI:
service ipmi start ipmitool mc reset cold service ipmi stop
To make the log format predictable, create /etc/fw/conf/logexport.ini with the following
For R70 (Secuplat):
[Fields_Info] included_fields=num,date,time,src,dst,proto,service,action,xlatesrc,xlatedst,peer gateway,<REST_OF_FIELDS>
For R77 (GAIA):
[Fields_Info] included_fields=date,time,src,dst,proto,service,action,xlatesrc,xlatedst,peer gateway,<REST_OF_FIELDS>
Create a directory for the converted logs:
mkdir /var/log/2019.txt
Run the following command to convert all logs, for example, for January 2019:
for i in $FWDIR/log/2019-01-*.log; do echo $i; fwm logexport -n -p -i $i | gzip -c - > /var/log/2019.txt/$i.txt.gz; done
Provided all route metrics are zeroes:
cat /etc/sysconfig/netconf.C | tr '(' ' '| tr ')' ' ' | tr '"' ' '| tr ':' ' ' | tr '\t' ' '| tr -s ' '| sed -e 's/^ //' | sed 's/routes//' | awk '/route/ {printf("set static-route ");} /dest/ {printf("%s ",$2);} /via/ {printf("nexthop gateway address %s ",$2);} /metric/ {print "on"}'
The result:
set static-route 10.13.198.160/27 nexthop gateway address 10.12.12.1 on set static-route 10.13.198.192/27 nexthop gateway address 10.12.12.1 on set static-route 192.168.112.0/24 nexthop gateway address 10.12.12.1 on set static-route 192.168.113.0/24 nexthop gateway address 10.12.12.1 on set static-route 192.168.114.0/24 nexthop gateway address 10.12.12.1 on set static-route 192.168.115.0/24 nexthop gateway address 10.12.12.1 on set static-route default nexthop gateway address 10.0.0.1 on
Sometimes you do not need a detailed log-analysis but several simple one-liners that you can adjust without too much thinking how it works, what you did last time, etc. The examples below are absolutely NOT optimal, but rather modular for easy line-editing.
1. Allowed traffic:
cat asa.log | grep permitted | grep access-list |
sed -e 's/^.*permitted//' -e 's/hit-cnt.*$//' |
sed -e 's/([0-9][0-9]*) ->/ ->/' | less
Result:
tcp outside/10.2.8.30 -> inside/10.1.141.23(8080)
tcp outside/10.2.8.30 -> inside/10.1.141.23(8080)
tcp outside/10.2.8.35 -> inside/10.1.140.137(13000)
udp outside/10.2.8.25 -> inside/10.1.9.14(137)
udp outside/10.2.8.25 -> inside/10.1.81.15(137)
tcp outside/10.2.8.44 -> inside/10.1.140.137(13000)
tcp outside/10.2.8.31 -> inside/10.1.140.149(13000)
Noticed the “permitted” strings?
2. Denied traffic:
cat asa.log | grep denied | grep access-list |
sed -e 's/^.*denied//' -e 's/hit-cnt.*$//' |
sed -e 's/([0-9][0-9]*) ->/ ->/' | less
Result:
tcp inside/10.1.140.159 -> outside/10.2.8.24(515)
tcp inside/10.1.140.159 -> outside/10.2.8.24(515)
tcp inside/10.3.241.116 -> outside/10.2.8.251(1541)
tcp inside/10.3.241.116 -> outside/10.2.8.251(1547)
tcp inside/10.1.140.159 -> outside/10.2.8.24(515)
3. The most popular permitted traffic:
cat asa.log | grep permitted | grep access-list |
sed -e 's/^.*permitted//' -e 's/hit-cnt.*$//' |
sed -e 's/([0-9][0-9]*) ->/ ->/' |
awk ' {conn[$0]++;} END { for ( i in conn ) print conn[i]," ",i;}' | sort +0nr | less
Result (the first column is the amount of corresponding log entries):
21170 tcp outside/10.2.8.40 -> inside/10.1.140.149(13000)
18023 tcp outside/10.2.8.34 -> inside/10.1.140.149(13000)
17981 tcp outside/10.2.8.31 -> inside/10.1.140.149(13000)
11034 tcp inside/10.1.140.251 -> outside/10.2.8.68(10001)
10652 tcp outside/10.2.8.43 -> inside/10.1.140.137(13000)
10628 tcp outside/10.2.8.44 -> inside/10.1.140.137(13000)
10484 tcp outside/10.2.8.47 -> inside/10.1.140.137(13000)
10437 tcp outside/10.2.8.23 -> inside/10.1.140.137(13000)
7618 tcp outside/10.2.8.25 -> inside/10.1.140.137(13000)
7550 tcp outside/10.2.8.27 -> inside/10.1.140.137(13000)
7515 tcp outside/10.2.8.49 -> inside/10.1.140.137(13000)
7496 tcp outside/10.2.8.29 -> inside/10.1.140.137(13000)
6826 tcp outside/10.2.8.30 -> inside/10.1.141.23(8080)
6011 tcp outside/10.2.8.35 -> inside/10.1.140.137(13000)
5896 tcp outside/10.2.8.40 -> inside/10.1.141.23(8080)
5809 tcp outside/10.2.8.30 -> inside/10.1.140.137(13000)
4. Modification for versions 8.2+:
cat asa.log | grep Deny | grep access-group | sed -e 's/^.*Deny//' -e 's/by.*$//' | sed -e 's/dst/ ->/' -e 's/src//' | less
You can use this method to generate a policy based on the current traffic.
Additional “greps” will allow you to filter for specific ports or IP-addresses.
Replace “permitted” with “denied” and you’ll get the “most popular denied traffic”.
Recently I’ve stumbled upon a strange looking site-to-site (CheckPoint R70 to Cisco VPN3k) VPN problem:
Connections from some networks were dropped with the following error:
Encryption failure: Received a cleartext packet within an encrypted connection
The first step was to check the encryption domains for the tunnel. In both GUI and /etc/fw/conf/user.def the encryption domain was the whole class B network, assigned to the company.
Next step was tracing.
Continue reading “Encryption failure: Received a cleartext packet within an encrypted connection”