One way ping from NS

network

(Van Vuong) #1

Hi All,

Recently i just install one NethServer for Transparent proxy at our Company.
This NS have 02 interface , one for Internet Access with have default GW , rest one is for Internal access without GW.
Internet <–> (ens224 - Red zone) NethServer (ens192 - Green Zone - 192.168.243.0/28) <–> (192.168.243.1)Cores SW (192.168.237.1) <–> Access SW <–> my PC (192.168.237.115/24)

All others VLans on my network will connect to internet through this NS - PRoxy, static route set on NS for my PC VLan

My issue is i only can ping to the NS (with very high latency) when the Ens224 (internet interface) is up, when this interface down, i cannot ping to NS anymore.

i have some test by removing the default route on interface Ens224, add the default on Interface Ens192, by this way i can ping to NS with normal latency (<1 ms)

i also try to remove Default Gw on both interfaces, adding 0.0.0.0/0 by static route with smaller metric for Ens224 but not success, only one route with destination 0.0.0.0/0 appear, otherwise it will override the old one.

Any advice ?
Thanks a lot,
Van.


(André Wismer) #2

Hi
Are you using vLans?
The text implies such, but no information on vLans in the above (Text) Network Description.

Unless you’re short of switches and just have one big manageable switch, but the szenario described above does not actually need any vLans (Making things more complex and harder to troubleshoot.)…

It might be a better idea to have a Gateway for the LAN, even if the users can’t reach the internet directly.
It should be the job of your firewall (Here NethServer) to block out access and only allow the Proxy Server direct access… (Block Ports 80 and 443 for Web for all except the NethServer itself.)

My 2 cents
Andy


(Michael Träumner) #3

I would say your clients should have the green interface as gateway.
And the red interface should have the address of the ISP router.

Please have also a look at this thread:


(Van Vuong) #4

Hi Andy,

Yes, we had alot of Vlan on the Core Switch, let say the vlan for my client is 237 (192.168.237.0) , the vlan for NS internal connection is 243 (192.168.243.0/240).
The GW for those vlan is the vlan interface on the core SW.


(Van Vuong) #5

Hi m.traeumner,

Yes, my current setting is exactly as what your advice, default gw only on red-internet interface, for the green-internal interface i leave the gw blank, and using static route for routing others subnets connection to core sw.

But not sure why I just can success with on way ping from NS to my client, no ping reach to NS from my pc


(André Wismer) #6

@vco

I’m not sure I quite understand the statement. The vLANs I deal with are usually with IP-Passiv Switches. Yes, Managed, but NO routing or anything else running on the switch.

If I understand this correct, this sounds like a routing problem. The Switch “routes” the IP traffic into different vLans, as is with the concept of vLans. However, it sounds to me like an additional subnet problem…

EG:

LAN 1
192.168.1.0/24

LAN 2
172.16.1.0/24 (Not 16 !!!)

LAN 3
172.16.2.0/24 (Again not 16!!!)

A typical case of Home worker (With 192.168.1.x on his home PC)
The LANs 2 & 3 are part of an Enterprise Network, say 2 sites, routed to each other.

IP-wise, both 172-Networks of the company could be defined as 172.16.0.0/16 or 172.16.0.0/255.255.0.0 - this could be used to “bundle” traffic, fw-rules and such.

Routing-Wise, you might get into major problems. The company can always reach your PC, but you can’t reach the company. Depending on your HW or Router, you might have to set 2 or more “routes”…

My 2 cents
Andy


(Van Vuong) #7

HI Andy,

I understood clearly the routing-wise which you mentioned above, and also sure this is not our problem.
Totally agree that this caused by routing issue , just not understand why when i put the default GW on the Red -Internet interface , the traffic is ok, and fail when i removed it. even this is Red, not the Green interface which i trying to connect.

Thanks,
Van.


(Van Vuong) #8

Hi m.traeumner, Andy,

i found the route cause, issue due to wrong NAT setting.

Thanks for your help,
Van.


(Michael Träumner) #9

Hi @vco,
thanks for your reply. Could you tell us where the error was in detail and mark this as answer please as solution?


(Van Vuong) #10

Hi m.traeumner,

there was a wrong setting on the our Core devices (with NAT enabled on the gateway interface). we removed the NAT and everything work perfectly.

Thanks,
Van.