Masquerading fails after replacing NICs

English Install/Boot/Login
1

Rebuilt a firewall box a few days ago and had to use two USB NICs - performance was horrible, but everything was working:

Public
Private
DMZ

Including the static route from Private directly to the DMZ.

Replaced the two USB NICs with PCI-E today, updated the configuration, and speed is back to normal, but the “Private -> DMZ” connection is broken. Reset/set the IP Forward and Masquerading options via Yast, no change. Compared the network config files to the last backup (old system, 13.2), couldn’t spot anything obvious. The old IF names are no longer present anywhere in Yast or the config directory.

Other than the “Masquerading” option (set) and “IP Forwarding” (set), what else might affect the configuration?

2

I’d start by checking the firewall rules operating in the chain. Compare the active interface names and the ‘iptables -L’ output

/sbin/ifconfig

sudo iptables -L
3

Another thought, check that the interfaces are in the appropriate firewall zones.

This reference may be of help to you…
https://doc.opensuse.org/documentation/leap/security/html/book.security/cha.security.firewall.html

4

Don’t see any interface names (new or old) in the current iptables rules, only:


forward_int  all  --  anywhere             anywhere            
forward_ext  all  --  anywhere             anywhere            
forward_dmz  all  --  anywhere             anywhere
5

Are the interfaces assigned to the correct zones?

6

They are in Yast, … but is there a way to verify that Yast is setting them correctly?

7

The interface zones are configured in /etc/sysconfig/SuSEfirewall2

These variables are relevant as described by comments in that file…

# For firewalls that should perform routing or masquerading between
# networks the settings FW_DEV_EXT, FW_DEV_INT, FW_ROUTE, FW_MASQUERADE,
# FW_SERVICES_EXT_TCP, and maybe FW_SERVICES_ACCEPT_EXT,  FW_FORWARD,
# FW_FORWARD_MASQ
8

FW_DEV_EXT=“eth0” (correct)
FW_DEV_INT=“p132p1” (correct)
FW_DEV_DMZ=“p128p1” (correct)
FW_ROUTE=“yes”
FW_FORWARD=“” (same as backup)
FW_MASQUERADE=“yes”
FW_FORWARD_MASQ=“” (same as backup)

Really weird that Yast seems to have updated SuSEfirewall2 correctly, and Private -> Public DOES work, but Private -> DMZ does not.

9

…and is the interface addressing/routing all in place?

10

Perhaps this is relevant?
https://en.opensuse.org/SuSEfirewall2#Masquerading

In particular

  • Allow the DMZ network full access to the net.

FW_MASQ_NETS=“10.1.1.0/24 192.168.1.0/24”

11

Interface addressing is correct, … the route is there for the DMZ, … just does not masquerade.

Just went through the 13.2 backup and set everything the same (except for IF names, of course), no difference.

12

Unsure how it would be applicable:


## Type:  string
#
# Which internal computers/networks are allowed to access the
# internet via masquerading (not via proxys on the firewall)?

Is “” now, … the backup was “0/0”, … tried “0/0” (““0/0” unrestricted access to the internet”), no difference. Private access to Internet is fine [luckily], …

13

I can only suggest you do a diff on the working openSUSE 13.2 /etc/sysconfig/SuSEfirewall2 and the Leap 42.2 config. Copy it across via memory stick then do something like

diff /etc/sysconfig/SuSEfirewall2 /path/to/other/SuSEfirewall2 |grep FW

FWIW, some firewall scenarios provided in /usr/share/doc/packages/SuSEfirewall2/EXAMPLES

14

Did not see anything interesting comparing the 13.2 version to the 42.2, … even tried the 13.2 version with the interface names changed - no connection Private -> DMZ.

so, … back to basics. Grabbed a virgin SuSEFirewall2 from a newly installed machine, assigned each of the three interface zones, ensured IP Forwarding was set in Network Configuration, and turned on Masquerading. NO JOY!! This is exactly what I did earlier this week; it worked just fine then, but not now.

Could there be a difference with the first version [working] using eth0, eth1, eth2, … while the current version uses eth0, p132p1, and p128p1?

Could anyone share a working 42.2 SuSEfirewall2 configuration with the three standard zones?

15

A bug report is the best course of action then.

16

Did you run mkintrd to discover new hardware??

17

What would that have to do with masquerading?

18

Not using the right drivers for the new hardware maybe.

19

Yes, but the interfaces would then not have been available to configure in the first place :wink:

20

NICs can be close but not exactly a like, small differences in the hardware may make a difference. I don’t know if that is the problem but you must use mkinird to discover any new hardware. Does not hurt to try :wink: