Some devices can't access internet on green

fruitful24 · 8 April 2020 08:07

Hello everybody.

I have been using ipfire for some time, but i have an unsolved problem. I’m trying to be a knowledgeable amateur, but I’m not a professional computer scientist, so I beg you to forgive me if I don’t always use the right vocabulary (and grammar).

I have the following configuration Red+Green+Orange. Orange is fully virtualized by a proxmox server. My ipfire is also virtualized. In orange i have three web servers that i can access from outside my home with the good firewall rules (http+https). Dyndns works fine from ipfire, when my box from my ISP changes its own ip adress, my no-ip account is well updated.

All the devices in orange can access internet off course, i mean i can ping www.google.fr or 8.8.8.8, i have a correct name resolution.

On green interface, i have a cabled network and wifi access provided by a netgear AP.

All the Windows computers (wireless or not) on green can access internet directly, while linux or custom firmware can’t directly (wireless or not)

The DHCP works fine, i have the correct IP address (sub-network, mask, gateway, DNS) but when i launch webrowser nothing happens. This problem also appears on my connected TV, good address but no internet access. Note i can’t ping computers on orange interface from computers on green interfaces when i have this issue.

This problem does not exist on windows computers. I have also connected objects that use wifi (weather station, google home) and this problem does not occur for them. I have access directly to all services hosted on orange interface. Finally, internet works fine for ps4, switch …

I have found a temporary solution. I connect in ssh to my ipfire in the green interface (192.168.2.1) with the root account. I ping the ip address on green that first does not have access ( ie 192.168.2.15), a few seconds later, when i have the feedback on the ping, the computer on green interface (192.168.2.15) has immediate access to internet and to hosts on orange. It works very well until the next reboot and i have to do the same process. Only once in twenty boots, the same computer has instant access to internet.

I use transparent proxy on green interface with the default settings. I have no custom settings (firewall,…) on my different computers.

Does anyone have any idea on how to fix this problem ?

Thank you

pike_it · 8 April 2020 13:30

Would you please give us a bit more information (starting from IP Subnets) on your setup?

fruitful24 · 8 April 2020 14:29

I am using this configuration

My ISP box is 192.168.1.1
My Red interface IPFire is 192.168.1.90 (config via ISP BOX)
My Green interface IPFire is 192.168.2.1
My Orange interface IPFire is 192.168.4.1

I haven’t drawn it, but i have a switch on Green LAN where devices are plugged

pike_it · 9 April 2020 01:01

Nice! A really understandable representation of your setup. Thank you
Now: which is the server DNS that DHCP Server is distributing?
Are you using Proxy server on IpFire for content filtering/bandwidth saving?
Are there any firewall rules from RED to GREEN or viceversa?

fruitful24 · 9 April 2020 07:52

Thank you.

The DHCP server provides 192.168.1.1 as DNS Server. When i put 192.168.2.1, nothing works at all. In IPFire, i’m not using anything else than my ISP DNS. Nothing is set for my BOX, i have leaved blank all the field in the web browser config page.

I am using transparent proxy server on green with the following config
Enabled on Green:||Proxy port: 800
Transparent on Green:||Transparent port: 3128.

On the same page i have checked the following boxes :
URL filter Enabled, i have young children at home, i am filtering adult content pages (only porn is checked on the config page)
Update accelerator Enabled
Disable internal proxy access to Green from other subnets.

It seems to me that i haven’t change any default config in the remaining items.

I have no idea where and how i can config bandwidth saving so i would say that i am not using it.

I have the following firewall rules

pike_it · 9 April 2020 15:33

Would you please try to disable transparent proxy as test?

fruitful24 · 10 April 2020 10:17

I have turned off proxy server, transparent proxy server and url filtering.

I have reboot several times my debian computer. It still has the good IP/subnet address but can’t go out to the net. But, if i wait for a random time which can range from one or two minutes to almost an hour, while not touching anything, it works. Same thing with my two connected tv.

In the mean time, windows 10 computer is still perfectly working with no delay.

I have also tested to turn off and turn on dhcp server to flush the dynamic leases.

fruitful24 · 5 May 2020 09:15

Hello everybody,

i still have the same problem. Does anybody have an idea ?

Thanks

pike_it · 5 May 2020 14:54

There’s any kind of device that have different network setups? I mean, for Windows and Linux computers, the installation of some virtualizer (VmWare Player/Workstation, Virtualbox, etc etc…)

krasnal · 5 May 2020 16:13

Would it be correct to say that your main problem is that Linux machines can’t immediately browse the Web after they start whereas Windows machines can?

You mentioned a workaround where you ping a Linux box from ipFire and the connection is then established. What you didn’t mention is whether you restricted your test to this one ping or whether you tried other combinations for pinging, for example:

Linux to ipFire gateway 192.168.2.1
Linux to router 192.168.1.1
Linux to Google DNS 8.8.8.8
Linux to Windows machine 192.168.2.x
Windows machine to Linux machine.
etc. (I’m sure you get the idea.)

Do any of these other pings also cause the Web browser to be able to see the Internet?

fruitful24 · 5 May 2020 16:53

On the green network i have almost only real and physical computers. I have only one server - jellyfin that is virtualized, running debian 10.

On the orange interfaces all my computers are virtualized and have no problem finding gateway and i can access them from outside directly.

At last, ipfire is virtualized.

fruitful24 · 5 May 2020 17:18

It would be almost correct if you say that. I would say instead that every machines that is not windows have nearly the same issue while the windows’one never face the problem. I’m not sure i’m clear on this one !?!?

My netatmo weather station seems to have no issue, like the google home or even the google cast plug. They have always worked.
My phones/tabs run android and face the problem but sometimes it works but not often. I have to ping them like Linux computers.
My two tv’s are from the LG (run LG web os) brand and they face the problem. I have to ping form ipfire and after that they can access internet.
My three Linux (two laptops and one desktop), computers like you have mentioned, don’t have direct access to internet and i have to ping them. Same problem for a chrome-os based laptop
At last, my two windows (one laptop and one desktop) have direct access to internet everytime i wake them up or i boot them from dark.

Here answers to your questions : you can change ‘linux’ by ‘not working computer’ and ‘windows’ by ‘working computer’. An example just after.

Linux to ipFire gateway 192.168.2.1 : does not ping
Linux to router 192.168.1.1 : does not ping
Linux to Google DNS 8.8.8.8 : does not ping
Linux to Windows machine 192.168.2.x : ping works
Windows machine to Linux machine.: ping works
Also, i can’t ping from green non-working computers to orange computers.

I add that if a Linux computer has access to internet, i can ping from it another linux computer that has no access to internet, it works. I can also ping a working linux computer from a non-working linux computer. So you can image every combination with working/non working computer like i have previously suggested.

A last thing, sometimes when i try to ping ipfire from a computer that initialy not ha acess to internet, ig i wait several minutes (i have never counted) it can works. But sometimes it never works, it seems to me that it is completly random.

Thanks for your help.

krasnal · 5 May 2020 18:12

These are all on the same subnet, so the ping to the gateway should work. The problem might be related to the fact that the gateway is running on a Proxmox VM, or possibly something in the switch that connects the devices on the 192.168.2.x subnet. (Is it a managed or unmanaged switch?)

Could run the following test and provide the output from each step:

On ipFire SSH run arp
Connect a Linux machine (preferably by cable), start it and once it’s started, run these commands from the command line:
arp
ip route get 192.168.2.1
route -n
ping -b -c5 192.168.2.255
arp
Back on ipFire again run arp

fruitful24 · 5 May 2020 19:58

i use a manageable switch cisco sg-300-28

Here the answers :

1/

* On ipFire SSH run `arp`

[root@ipfire ~]# arp
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.4.22             ether   86:ef:b0:14:21:f0   C                     orange0
192.168.2.35                     (incomplete)                              green0
192.168.1.20             ether   d4:ae:52:b7:9e:9b   C                     red0
192.168.2.31             ether   18:31:bf:8d:8c:98   C                     green0
192.168.2.21             ether   78:5d:c8:87:b7:e1   C                     green0
192.168.2.250            ether   14:59:c0:a1:3d:d2   C                     green0
192.168.2.26             ether   0c:8f:ff:5c:a9:e5   C                     green0
192.168.2.16             ether   44:09:b8:11:a9:e9   C                     green0
switchbacbc5.home        ether   d4:e6:b7:ec:0b:ef   C                     green0
192.168.2.12             ether   70:ee:50:2b:3c:fe   C                     green0
cisco.home               ether   1c:df:0f:ba:cb:c5   C                     green0
192.168.1.234                    (incomplete)                              red0
MediaCenter.home         ether   00:09:b0:f3:8d:45   C                     green0
192.168.2.23                     (incomplete)                              green0
Google-Home-Mini.home    ether   3c:2a:f4:b5:18:09   C                     green0
192.168.4.11             ether   26:5e:6d:65:97:2c   C                     orange0
didis-E1-510.home                (incomplete)                              green0
192.168.2.32                     (incomplete)                              green0
192.168.2.38             ether   30:10:b3:78:e2:86   C                     green0
PyDownload.home          ether   7e:75:89:fa:52:55   C                     green0
192.168.2.18             ether   c0:41:f6:05:ad:59   C                     green0
Gaming.home              ether   e0:d5:5e:bc:d1:33   C                     green0
192.168.4.30             ether   8a:79:13:fb:1b:ad   C                     orange0
didis-E1-510.home                (incomplete)                              green0
Chromecast-Ultra.home    ether   e0:24:81:44:a1:70   C                     green0
192.168.2.19             ether   02:71:22:89:66:b0   C                     green0
Netatmo.home             ether   04:03:d6:54:f6:f4   C                     green0
192.168.2.34             ether   94:44:44:34:12:dd   C                     green0
192.168.2.24             ether   f8:a9:63:0b:30:cf   C                     green0
Nucleus.home             ether   ae:6d:4f:84:d7:75   C                     green0
gateway                  ether   44:ce:7d:9f:e1:c0   C                     red0
192.168.2.20             ether   00:04:74:0f:a3:ff   C                     green0
LGwebOSTV.home           ether   20:df:b9:a1:bb:4b   C                     green0

2/

Connect a Linux machine (preferably by cable), start it and once it’s started, run these commands from the command line:

arp

didis@didis-E1-510:~$ arp
Adresse                  TypeMap AdresseMat          Indicateurs           Iface
192.168.2.2              ether   1c:df:0f:ba:cb:c5   C                     enp1s0f2
192.168.2.13             ether   3c:2a:f4:b5:18:09   C                     enp1s0f2
192.168.2.1              ether   d4:ae:52:b7:9e:9d   C                     enp1s0f2
192.168.2.21                     (incomplet)                               enp1s0f2

ip route get 192.168.2.1

`ip route get 192.168.2.1`

didis@didis-E1-510:~$ ip route get 192.168.2.1
192.168.2.1 dev enp1s0f2 src 192.168.2.24 uid 1000 
    cache

route -n

`route -n`

didis@didis-E1-510:~$ route -n
    Table de routage IP du noyau
    Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
    0.0.0.0         192.168.2.1     0.0.0.0         UG    20100  0        0 enp1s0f2
    169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 enp1s0f2
    192.168.2.0     0.0.0.0         255.255.255.0   U     100    0        0 enp1s0f2

ping -b -c5 192.168.2.255

`ping -b -c5 192.168.2.255`

didis@didis-E1-510:~$ ping -b -c5 192.168.2.255
WARNING: pinging broadcast address
PING 192.168.2.255 (192.168.2.255) 56(84) bytes of data.
64 bytes from 192.168.2.20: icmp_seq=1 ttl=255 time=0.391 ms
64 bytes from 192.168.2.16: icmp_seq=1 ttl=64 time=0.451 ms (DUP!)
64 bytes from 192.168.2.2: icmp_seq=1 ttl=64 time=2.06 ms (DUP!)
64 bytes from 192.168.2.10: icmp_seq=1 ttl=64 time=44.3 ms (DUP!)
64 bytes from 192.168.2.20: icmp_seq=2 ttl=255 time=0.562 ms
64 bytes from 192.168.2.16: icmp_seq=2 ttl=64 time=0.624 ms (DUP!)
64 bytes from 192.168.2.2: icmp_seq=2 ttl=64 time=1.67 ms (DUP!)
64 bytes from 192.168.2.10: icmp_seq=2 ttl=64 time=64.8 ms (DUP!)
64 bytes from 192.168.2.16: icmp_seq=3 ttl=64 time=0.473 ms
64 bytes from 192.168.2.20: icmp_seq=3 ttl=255 time=0.600 ms (DUP!)
64 bytes from 192.168.2.2: icmp_seq=3 ttl=64 time=2.03 ms (DUP!)
64 bytes from 192.168.2.10: icmp_seq=3 ttl=64 time=88.1 ms (DUP!)
64 bytes from 192.168.2.20: icmp_seq=4 ttl=255 time=0.472 ms
64 bytes from 192.168.2.16: icmp_seq=4 ttl=64 time=0.531 ms (DUP!)
64 bytes from 192.168.2.2: icmp_seq=4 ttl=64 time=2.03 ms (DUP!)
64 bytes from 192.168.2.10: icmp_seq=4 ttl=64 time=8.21 ms (DUP!)
64 bytes from 192.168.2.20: icmp_seq=5 ttl=255 time=0.360 ms

--- 192.168.2.255 ping statistics ---
5 packets transmitted, 5 received, +12 duplicates, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 0.360/12.801/88.065/25.685 ms

arp

`arp`

didis@didis-E1-510:~$ arp
Adresse                  TypeMap AdresseMat          Indicateurs           Iface
192.168.2.1              ether   d4:ae:52:b7:9e:9d   C                     enp1s0f2
192.168.2.2              ether   1c:df:0f:ba:cb:c5   C                     enp1s0f2
192.168.2.10             ether   20:df:b9:a1:bb:4b   C                     enp1s0f2
192.168.2.13             ether   3c:2a:f4:b5:18:09   C                     enp1s0f2
192.168.2.20             ether   00:04:74:0f:a3:ff   C                     enp1s0f2
192.168.2.21                     (incomplet)                               enp1s0f2
192.168.2.16             ether   44:09:b8:11:a9:e9   C                     enp1s0f2

3/ * Back on ipFire again run arp

Summary

[ root@ipfire ~]# arp
Address HWtype HWaddress 192.168.4.22 ether 86:ef:b0:14:21:f0 C 192.168.2.35 (incomplete) 192.168.1.20 ether d4:ae:52:b7:9e:9b C 192.168.2.31 ether 18:31:bf:8d:8c:98 C 192.168.2.21 ether 78:5d:c8:87:b7:e1 C 192.168.2.250 ether 14:59:c0:a1:3d:d2 C 192.168.2.26 ether 0c:8f:ff:5c:a9:e5 C 192.168.2.16 ether 44:09:b8:11:a9:e9 C switchbacbc5.home ether d4:e6:b7:ec:0b:ef C 192.168.2.12 ether 70:ee:50:2b:3c:fe C cisco.home ether 1c:df:0f:ba:cb:c5 C 192.168.1.234 (incomplete) MediaCenter.home ether 00:09:b0:f3:8d:45 C 192.168.2.23 (incomplete) Google-Home-Mini.home ether 3c:2a:f4:b5:18:09 C 192.168.4.11 ether 26:5e:6d:65:97:2c C didis-E1-510.home (incomplete) 192.168.2.32 (incomplete) 192.168.2.38 ether 30:10:b3:78:e2:86 C PyDownload.home ether 7e:75:89:fa:52:55 C 192.168.2.18 ether c0:41:f6:05:ad:59 C Gaming.home ether e0:d5:5e:bc:d1:33 C 192.168.4.30 ether 8a:79:13:fb:1b:ad C didis-E1-510.home (incomplete) Chromecast-Ultra.home ether e0:24:81:44:a1:70 C 192.168.2.19 ether 02:71:22:89:66:b0 C Netatmo.home ether 04:03:d6:54:f6:f4 C 192.168.2.34 ether 94:44:44:34:12:dd C 192.168.2.24 ether f8:a9:63:0b:30:cf C Nucleus.home ether ae:6d:4f:84:d7:75 C gateway ether 44:ce:7d:9f:e1:c0 C 192.168.2.20 ether 00:04:74:0f:a3:ff C LGwebOSTV.home ether 20:df:b9:a1:bb:4b C Flags Mask Iface
orange0
green0
red0
green0
green0
green0
green0
green0
green0
green0
green0
red0
green0
green0
green0
orange0
green0
green0
green0
green0
green0
green0
orange0
green0
green0
green0
green0
green0
green0
green0
red0
green0
green0

krasnal · 6 May 2020 07:53

Thanks. I’ll take a look at it this evening, when I have some free time.

Could you confirm that the Linux device was freshly started when you ran the tests?

I also forgot to test that in this particular case the ping to the gateway was still failing. My bad.

fruitful24 · 6 May 2020 15:27

Hello,

After this remark i have check all the configuration of the switch. The one i understand off course. Nothing seems to me to be wrong. But, once again, i am not a pro.

Then I went to check proxmox settings. Firs of all, i have found that indeed firewall was not disabled by default on the VM that was running ipfire. Once this settings unchecked ping from Linux machine to ipfire worked. As you mentionned, they were on the same subnet they shoul communicate directly with or witout internet passtrough.

This research made me realize my mistake, the one that blocked everything. I have assigned to the virtual switch to which Ipfire is connected under proxmox the same address as Ipfire itself. Two different objects with the same IP address … a beginner’s error ! Which I saw 10 times without telling myself that it was the real problem !! I have convinced myself that it was logical that Ipfire which was the only computer plugged to the virtual switch and the switch must have the same IP when precisely they had to have a different one !

Once I have removed this mistake, everything is working. I only have a few hours of hindsight, but all the devices I have (TV, smartphone …) find the IP address via DHCP and have instant access from the green interface to both the internet and orange interface computers.

So, thank you so much for your help, thanks to you i have finally found what i was looking for ! I allow myself a few days of feedback to declare victory but sincerely I believe in it this time

krasnal · 6 May 2020 16:02

Excellent news. Thanks for the detailed feedback and I hope it all continues to work successfully.

pike_it · 7 May 2020 20:32

Long story short: more time reviewing (and debugging) network project means less time trapped into obvious errors.

@fruitful24 no offense intended