[opensuse 13.2] repositories access from local network

soundlord · February 1, 2017, 1:42pm

Greetings !!

I wonder why when, in the laboratory, when trying to update local computers from the LAN there is some “unknown error: connection reset by peer”: either using online update/packagekit/zypper ?

We could have a better performance if we do not pass thru the router, with the cable directly connected to the output server of the school but I only could try this for three computers at all (close to the short cable).

The router is a Linux Box with two network interfaces: the one serving the 192.168.1.0 network and the other serving the 172.16.0.0 network.
This router does SNAT to make all requests from the inner network 192.168.1.0 to be taken as 172.16.0.254 (the interface connected to the 172.16.0.0 network).
I use iptables and ip6tables, the rules will be given tomorrow as I did not work today and can’t remember with precision the rules I made.

I cut the ipv6 traffic dropping all packets from both interfaces:



ip6tables -F

ip6tables -P INPUT DROP
ip6tables -P OUTPUT DROP
ip6tables -P FORWARD DROP

ip6tables -P -t nat PREROUTING DROP
ip6tables -P -t nat POSTROUTING DROP
ip6tables -t nat -P INPUT  DROP
ip6tables -t nat -P OUTPUT  DROP

ip6tables -A INPUT -i eth0 -j DROP
ip6tables -A OUTPUT -o eth0 -j DROP

ip6tables -A INPUT -i eth1 -j DROP
ip6tables -A OUTPUT -o eth1 -j DROP

Concerning ipv4, I accept all packets from eth1 (local network interface) and route them to eth0 (school network).
It works as I could ping the 172.16.0.1 server from any computer from the local network.
Using traceroute I can see each time that we hop from 192.168.1.254 to 172.16.0.254 and then to the route given… the Linux Box routing seems working.

When using zypper we can see the download starting at 1400K/s and once reached 90% the connexion drops to 1K/s and then the error occurs (time out ???).

More informations to come: I forgotten to send the screenshots so I will have them tomorrow as I do not work today.

The network has fifteen 13.2 computers equipped with Gb network cards. All these computers are linked to a single Gb switch and this one connected to the main category 6 ethernet cable to the outside network.
I asked for this week to separate the class into two Gb switches but I’m not sure the problem is isolated to the performances of this switch, the internet works fine, sometimes we got the main router (outside of our network) that can not route no more.

When this happen we can see using traceroute that there is H! signals after the 172.16.0.1 (the outside server) just as: 172.16.0.1 H! H! H!
It takes one minute to recover and then we could again connect to the internet.

How can I diagnose the issue using WireShark ? I did it one time but nothing at screen could tell me what was wrong using the update/zypper/package kit features.

Thank you in advance and apologies for the poor descriptions, I will tomorrow bring more pictured elements to let you see what is going on and determine if we are cursed or we just have a weak network administrator.

tsu2 · February 1, 2017, 6:49pm

The more you know how Ethernet works, you’ll find less mystery. One major concept is that Ethernet is a serial communication, which means that only one packet can “light up” on an entire physical network segment at a time. Once you understand this, then it might become more important to configure dedicated physical connection links for various high priority uses, or at least set up completely segregated networks to guarantee QoS (eg for VoIP).
Depending on the topology, components and design of your LAN you may be experiencing packet losses associated with out of order, outright loss, or extreme latencies. Every device has TCP/IP buffers and Layer 3 (sometimes Layer 2) sliding windows and TTL settings that try to address problems causes by things like massively limited or massively large (yes! that can also be a problem) throughput, buffers, EMF, device chokepoints and plenty more. About a decade ago I wrote the following, the concepts are still 100% still current today which describe this and more, and how to address. Anyone who is running any kind of network connection other than “Fast Ethernet” (10/100) 802.3 (wired), this is a must-read if you want efficient, high throughput.

https://sites.google.com/site/4techsecrets/optimize-and-fix-your-network-connection

TSU

soundlord · February 1, 2017, 9:15pm

Wonderful !! Something to read tonite ^^

Thanx…

soundlord · February 2, 2017, 6:41pm

I’m coming back…

I read with full focus the different articles related to the original article you posted and I find it really helpful.
I did some tests here on local network with four computers all configured with the same settings and with same os… except one with LEAP 42.1, nothing strange to be related.

I did the same tests on different computers in the labo… with the same settings. I have one improvement, some updates with less than 150Mo of size could be downloaded if I click “retry” on GUI… with zypper it doesn’t work (whatever the size of the package). But some packages still stuck at 98% (in PackageKit or online-update) and then I got a “unknown error: connexion reset by peer”…

This is the iptables rules I set for the Linux Box… eth0 is configured as 172.16.0.254 and eth1 is configured as 192.168.1.254, eth0 serve the input/output for the cable that goes straight to the school server, eth1 serves the local network of the lab.
I guess I did something wrong because when I put the cable directly to the target computer, the download won’t be interrupted at all.


#! /bin/bash

# flush the default firewall settings
iptables -F

#don't let the DHCP requests going inside the local network from the outside

iptables -A INPUT -i eth0 -p tcp --sport 67:68 --destination 172.16.0.0/16 -j DROP

#log them 

iptables -A INPUT -i eth0 -p tcp --sport 67:68 --destination 172.16.0.0/16 -j LOG --log-prefix "[dhcp to eth0]"

#stop the broadcasts from other networks at the input of our Linux Box   

iptables -A INPUT -i eth0 -p udp --sport 137 --destination 172.16.31.255 -j DROP 

# let the DNS requests going thru eth1 

iptables -A INPUT -p tcp --dport 53 -i eth1 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -i eth1 -j ACCEPT

# limit the xdmcp protocol to a specific computer

iptables -A INPUT -p tcp ! -s 192.168.1.16 --dport 177 -i eth1 -j DROP
iptables -A INPUT -p udp ! -s 192.168.1.16 --dport 177 -i eth1 -j DROP


# limit the ssh protocol to a specific computer

iptables -A INPUT -p tcp ! -s 192.168.1.16 --dport 890 -i eth1 -j REJECT --reject-with tcp-reset
iptables -A INPUT -p tcp ! -s 192.168.1.16 --dport 6000 -i eth1 -j REJECT --reject-with tcp-reset



# input rules  
iptables -A INPUT -i eth0 -j ACCEPT
iptables -A INPUT -i eth1 -j ACCEPT

# forward packets from eth0 to eth1 and vice versa

iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

# nat (source nat)
# make things to hide the source IP from local network to let the outside equipment send back the answers (the door to our local network is seen as 172.16.0.254 from the outside)

iptables -t nat -F
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT --to-source 172.16.0.254

#iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT --to-source 192.168.1.1
# cut the ipv6 traffic

ip6tables -F
ip6tables -P INPUT DROP
ip6tables -P OUTPUT DROP
ip6tables -P FORWARD DROP
ip6tables -A INPUT -i eth0 -j DROP
ip6tables -A INPUT -i eth1 -j DROP

I can’t see which rules could mess up the downloads of the packages coming from trusted repositories…
But in the other hand, I’m not an iptables guru nore networks guru.