[Shorewall-users] Forwarding on internal interface

[Bill Shirley]

I've seen this on a couple of networks I administer. I think it's Winwoes 10 related. I began
seeing this behavior about the time Microsoft started rolling out Winwoes 10.

My theory is that Winwoes 10 is looking up the printer name via DNS and then assuming
that the printer will always have that address. I'm thinking it re-configures itself to access
the printer strictly by IP address. Then when the printer gets a different IP address (DHCP),
it can't lookup the MAC address via arp. So it decides to let the gateway do the work of
forwarding the request (which it can't do because the printer isn't at that address anymore).
Currently I just DROP this non-sense.

Look at the printer configuration on the Windows machine and see if it has a hard coded
IP address.

Bill

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,
I have a two-interface shorewall setup with one side on a
192.168.0.0 network while the other is connected to the Internet
via a cable modem.
There's a Win10 machine on the internal network that appears to be
sending out snmp requests to the network printer, and I can't
understand why shorewall is rejecting them.
Dec 20 19:50:43 orion kernel: Shorewall:FORWARD:REJECT:IN=eth1
OUT=eth1 MAC=0c:c4:7a:a9:18:df:52:54:00:52:6b:61:08:00
SRC=192.168.1.18 DST=192.168.1.104 LEN=106 TOS=0x00 PREC=0x00
TTL=127 ID=17640 PROTO=UDP SPT=50731 DPT=161 LEN=86
In my policy file I have allowed internal to internal
int int ACCEPT
I've also checked to make sure there aren't any explicit rules to
block port 161 or snmp.
Does anyone have any idea what could be causing this, or how I can
troubleshoot it further? How do I identify which rule is causing
this to be rejected?

The first question is "Why does 192.168.1.18 think it needs to route
packets to 192.168.1.104 through your Shorewall router?". It can
obviously send them directly on the local LAN. I assume that is
because 192.168.1.18 has the wrong netmask configured - a netmask that
makes it look like 192.168.1.104 is not on its local network".
The reason that the Shorewall-generated ruleset is blocking the
traffic is that you haven't specified 'routeback' in the eth1 entry in
/etc/shorewall/interfaces. This is made clear in Shorewall FAQ 17.
- -Tom
- --
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJYWevPAAoJEJbms/JCOk0QjioP/1kBMnOcTX8+RwST8DM+j2Q0
FO+DhSrwi/HgdSaq++X7F330IiAu1sMyde3Bmmw06nMevKYuvyP6zdvDdNqTDa4K
SEf2GmZcl99sddKuyXwbC+6roc4l2W7eJKDLj6ClyW+ilnhRAkhsb2ndu6TMz+bm
V/b6QrHAxmzckR+DLgsGp50gWFrxkUhU7xoUtZXSRzIw7xZYRWNsAU4P14noVhwV
/nS+r/t2hXeIRMSMPPwKSh41G2+HvWsgTWk3jNEUw1lszD0wB8HJ400QPxXGC3jl
3el1Ms1n4zbF/LR4ZG6hud7EoW4uCTKQbFfhyHEWN88KiyUpX/PFF0w5aMPcXzup
NJnpj2a87rAIhV9ATEU+Ax8pKmTKMmScgp4V+LkzEsyEbUwoP43KaNvEYtn6RCiX
2JYc9bOrnRw3CS3BGSckeK9z8AcyWTtKXVkUYjWdDXIK6THtiLioVRYEuPaSA/v9
S3L35y5MFCHvN2Cv+vq9HpVDjX2vBuymsNYmS6SoIAMTRL6Dk4kOo3MPVCazsgoB
pLZwVQbMbhZZCXeFqJUMUW5fAtPmJsywkVO/ZUqi3fhPyDFpEPFy9nW9eeZaLtV+
A1lDCc5DvdaKkqpA4ArTjNkCE9NGqINrazJ0UnKWKArQoJzpq+SuKOYQpx/NWZeq
KuWKwhJqqFiNCMWKuTZI
=CMJG
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
_______________________________________________
Shorewall-users mailing list
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Alex]

Hi,

On Thu, Dec 22, 2016 at 11:32 PM, Bill Shirley

Post by Bill Shirley
I've seen this on a couple of networks I administer. I think it's Winwoes 10 related. I began
seeing this behavior about the time Microsoft started rolling out Winwoes 10.
My theory is that Winwoes 10 is looking up the printer name via DNS and then assuming
that the printer will always have that address. I'm thinking it re-configures itself to access
the printer strictly by IP address. Then when the printer gets a different IP address (DHCP),
it can't lookup the MAC address via arp. So it decides to let the gateway do the work of
forwarding the request (which it can't do because the printer isn't at that address anymore).
Currently I just DROP this non-sense.
Look at the printer configuration on the Windows machine and see if it has a hard coded
IP address.

Only now seeing this. Yes, you are correct, the printer is hard-coded.
I've now fixed it by just dropping them. I also implemented Tom's
suggestion of using "routeback" on the internal interface, but I'm now
noticing it didn't fix it.

I'm curious why the routeback option didn't work?

It's a samba printer, so I had trouble browsing by name. Would
figuring out the issue I have with browsing by name be the right fix?

Thanks,
Alex

[Bill Shirley]

The "routeback" option tells Shorewall to build chains to manage int <-> int traffic. With
"routeback", your policy should take effect as well as any rules like:
DROP int int tcp snmp

As far as Windows name resolution, I run Samba with "wins support = yes" and at DHCP
time pass out "option netbios-name-servers".

Bill

Post by Alex
Hi,
On Thu, Dec 22, 2016 at 11:32 PM, Bill Shirley

Post by Bill Shirley
I've seen this on a couple of networks I administer. I think it's Winwoes 10 related. I began
seeing this behavior about the time Microsoft started rolling out Winwoes 10.
My theory is that Winwoes 10 is looking up the printer name via DNS and then assuming
that the printer will always have that address. I'm thinking it re-configures itself to access
the printer strictly by IP address. Then when the printer gets a different IP address (DHCP),
it can't lookup the MAC address via arp. So it decides to let the gateway do the work of
forwarding the request (which it can't do because the printer isn't at that address anymore).
Currently I just DROP this non-sense.
Look at the printer configuration on the Windows machine and see if it has a hard coded
IP address.

Only now seeing this. Yes, you are correct, the printer is hard-coded.
I've now fixed it by just dropping them. I also implemented Tom's
suggestion of using "routeback" on the internal interface, but I'm now
noticing it didn't fix it.
I'm curious why the routeback option didn't work?
It's a samba printer, so I had trouble browsing by name. Would
figuring out the issue I have with browsing by name be the right fix?
Thanks,
Alex
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Shorewall-users mailing list
https://lists.sourceforge.net/lists/listinfo/shorewall-users