Troubleshooting
Problem
After Upgrading a QRadar Deployment to 7.3.0 you discover that the NFS mounts are no longer working. You determine the mount point is correct, but you are not able to connect to the NFS server.
Symptom
The backups were not being remotely stored on the backup server after the upgrade.
Cause
The interfaces changed from eth to en for predictable network interfacing naming, but the custom firewall rules still reference the old interface naming convention. To determine this do these commands
Type route -n shows interface ens3 as the network subnet were the NFS backup server is on.
[root@QRada73 ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 ens3
169.254.2.0 0.0.0.0 255.255.255.0 U 0 0 0 docker0
169.254.3.0 0.0.0.0 255.255.255.0 U 0 0 0 dockerApps
169.254.4.0 0.0.0.0 255.255.255.0 U 0 0 0 appProxy
172.17.0.0 0.0.0.0 255.255.255.0 U 0 0 0 ens4
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 ens3
Type cat /opt/qradar/conf/iptables.pre which shows Interface eth0 associated with the subnet.
[root@QRada73 ~]# cat /opt/qradar/conf/iptables.pre
-I INPUT -p tcp --dport 10101 -j ACCEPT
-I INPUT -p tcp --dport 445 -j ACCEPT
-A INPUT -i eth0 -s 192.168.0.23 -j ACCEPT
Resolving The Problem
Upgrading to QRadar 7.3.0 will cause the interfaces to change from eth to a value of en. This is to account for the change to predictable Network Interface device naming. Prefix's are applied after en to represent hardware which use either o or p. A virtual machine will use prefix s
Example en<s>3 where
o = on-board device
s = hotplug slot
p = PCI location.
If your iptables custom firewall rule in /opt/qradar/conf/iptables.pre is referencing an interface prior to the upgrade you need to update it with the correct interface name.
Example if your firewall rule before you upgraded was something like this
-A INPUT -i eth0 -s 192.168.0.23 -j ACCEPT
You will need to update it to include the new interface.
-A INPUT -i ens3 -s 192.168.0.23 -j ACCEPT
Steps to resolve the issue.
- Using an SSH session log in to the QRadar Console.
- Type ifconfig to determine the interface that is associated with the subnet for the backup server.
[root@QRada73 ~]# ifconfig
ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.80 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::5054:ff:fef0:a86 prefixlen 64 scopeid 0x20<link>
ether 52:54:00:f0:0a:86 txqueuelen 1000 (Ethernet)
RX packets 109 bytes 17491 (17.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 84 bytes 10626 (10.3 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ens4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.17.0.24 netmask 255.255.255.0 broadcast 172.17.0.255
inet6 fe80::5054:ff:fe0e:c022 prefixlen 64 scopeid 0x20<link>
ether 52:54:00:0e:c0:22 txqueuelen 1000 (Ethernet)
RX packets 3 bytes 210 (210.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 8 bytes 850 (850.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
- Using vi editor open /opt/qradar/conf/iptables.pre
vi /opt/qradar/conf/iptables.pre - Change the entry for the interface from eth to the one listed in the output of the ifconfig command that corresponds to the one for the subnet were the backup server.
- Save the changes by typing esc :wq
- Update the iptables configuration using the command
/opt/qradar/bin/iptables_update.pl - restart the NFS services using these commands
systemctl restart rpcbind
systemctl restart nfs-server
Results:
You now connect to your NFS Backup Server.
For more information on Configuring NFS shares for backups, look at this Knowledge Center article.
Moving backups to an NFS
Where do you find more information?
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg22007532