To see all my blog posts on IP filtering see here.
If you are using Communications Server IP filtering to allow/deny IP traffic to destinations, you need the TMDR daemon running. TMDR writes messages to the syslogd which can write them to a file
The trace output is like
EZD0815I Packet denied by policy: 11/17/2023 13:09:17.00 filter rule= Colin ext= 2 sipaddr=10.1.0.2 dipaddr= 10.1.1.2 proto= icmp(1) type= 8 code= 0 -=
Interface= 10.1.1.2 (I) secclass= 255 dest= local len= 84 vpnaction= N/A
tunnelID= N/A ifcname= ETH1 fragment= N
The request
- came from 10.1.0.2 ( the Source IP ADDRress)
- going to 10.1.1.2 the (Destination IP ADDRess
- The protocol was icmp. Within the IP protocol an icmp packet has type 1.
- Type is Echo request (used to called ping), and icmp packet with type 8. See here.
- The name of the z/OS interface definition ETH1. See NETSTAT DEVLINKS
- The IP address of the interface 10.1.1.2
- The packet was inbound(I)
- There was a keyword with no value -= … this is useful when parsing the traffic, because it shows a null object.
Using the Unix System Services command
ipsec -p TCPIP -f display > a
This gave
... FilterName: Colin FilterNameExtension: 1 ... Direction: Outbound ... FilterName: Colin FilterNameExtension: 2 ... Direction: Inbound
From filter rule= Colin ext= 2 we can see this was inbound.
With an input file
IpFilterPolicy
{
PreDecap off
FilterLogging on
IpFilterLogImplicit yes
AllowOnDemand yes
IpFilterRule Colin
{
IpSourceAddr 10.1.1.2
IpDestAddr All
IpService
{
Protocol all
Direction bidirectional
Routing local
}
IpService
{
# PING ICMP type 8
Protocol icmp Type 8
Direction bidirectional
Routing local
}
IpGenericFilterActionRef permit
IpService
{
#
Protocol icmp Type 9
Direction bidirectional
Routing local
}
}
With Direction bidirectional it creates two rules, one in bound, and one outbound.
When PING was performed – this was rule 4 – from the bold text.
One thought on “CS IP filtering: understanding logged messages”