Github pagina werkt niet op linux devices

[royalt123]

Mijn vraag:
Vandaag was ik bezig met Kali linux vm te installeren en kwam achter dat 1 website niet werkt en dat is github.com.
Alsook bij git clone via cli.

Relevante software en hardware die ik gebruik:
Intel nuc met esxi hypervisor.
Mijn werk laptop.
Er draait pihole.
Er draait Barracuda firewall (niet particulier merk).

Wat ik al gevonden of geprobeerd:
Kali linux achter virtueel router pfsense.
Kali linux opnieuw geïnstalleerd.
Kali linux vm installatie maar dan op mijn pc met vmware workstation. Website werkte enkel als vm op nat staat ipv bridge wat ook raar is.

User agent profile als windows gezet in Firefox op kali linux.

Pihole afgezet.
Bij kali linux gateway veranderd naar ander firewall (watchguard).

Op mijn Google pixel werkt het ook niet (Android aka linux?)
Als ik mijn gsm op 4g doet dan laadt pagina wel.

Echter op alle fysiek als virtueel Windows machine werkt het wel zonder probleem

De Firewall heeft geen aanpassing gehad tussentijds dus in principe kan het niet daar aan liggen.

Ik ben netwerk engineer dus je kan technisch diep gaan.

[ Voor 4% gewijzigd door royalt123 op 27-10-2023 09:29 ]

[deHakkelaar]

code:

curl -ILv github.com

?

[Douweegbertje]

royalt123 schreef op vrijdag 27 oktober 2023 @ 00:23:

Ik ben netwerk engineer dus je kan technisch diep gaan.

->

niet werkt

Wij zijn ook technisch - Begin eerst eens met "wat werkt er niet"? (Bovenstaande curl is al een goede )

[royalt123]

Het komt vast te zitten tijdens query.




Firewall zegt tcp drop bij linux bak:



Firewall zegt tcp ok bij Windows bak:

deHakkelaar schreef op vrijdag 27 oktober 2023 @ 01:33:

code:

curl -ILv github.com

?

[MasterL]

Zit de Kali vm in hetzelfde vlan/broadcast domain als jouw fysieke machines?

[Raven]

Dit lijkt vergelijkbaar met wat ik met Telegram.org had, daar bleek het uiteindelijk om een IPv6-gerelateerd MTU-probleem te gaan. Gezien de cURL output gaat die oorzaak hier niet op, althans, het IPv6 deel.

[RobIII]

@Raven Nee, inderdaad, niet het IPv6 deel, maar ik gok dat een MTU wel een goeie is om eens te checken. Heb ook al eens zoiets gehad en toen was 't ook MTU gerelateerd (MSS clamping als ik me goed herinner).

[ Voor 33% gewijzigd door RobIII op 27-10-2023 09:46 ]

[royalt123]

Ja, zit ook in hetzelfde netwerk/vlan. Ik zal nu op ander esxi ook even rap testen waar Windows VM zitten.
Maar gezien gsm dat issue ook heeft denk ik niet daar aan ligt. Had ik maar windows phone om te testen

MasterL schreef op vrijdag 27 oktober 2023 @ 09:39:
Zit de Kali vm in hetzelfde vlan/broadcast domain als jouw fysieke machines?

[Raven]

RobIII schreef op vrijdag 27 oktober 2023 @ 09:45:
@Raven Nee, inderdaad, niet het IPv6 deel, maar ik gok dat een MTU wel een goeie is om eens te checken. Heb ook al eens zoiets gehad en toen was 't ook MTU gerelateerd (MSS clamping als ik me goed herinner).

Hier loste AdvLinkMTU 1460; in radvd.conf het op.

[royalt123]

@Raven @RobIII
MTU is inderdaad een goed punt, ik heb er al genoeg ervaring mee op het werk. Ik heb de MTU op Linux aangepast, maar dat heeft het probleem niet opgelost.

Ik heb Kali getest op een andere ESXI, met hetzelfde netwerk als de Windows VM, maar het probleem doet zich alleen voor bij Linux. Ik heb ook naar andere Linux VM’s gekeken en ze hebben allemaal hetzelfde probleem bij de curl -ILv output.

[Ultraman]

Misschien een idee om een tcpdump te maken op de client en die te delen?
En als je er een packet capture te maken is op de firewall dan is dat handig.

[laurens0619]

Op barracuda pagina staat dit:

TCP Packet Belongs to no Active Session
The message can be regarded as purely informational and as an indicator that a TCP session has terminated slightly "out of order". However, it is helpful to know the factors that contribute to unscheduled session termination or to frequent TCP packets that cannot be allotted to an active session.

Situation 1
Two computers deciding to close their TCP communication do so by exchanging finalization (FIN) and acknowledgment (ACK) messages. A typical connection termination requires a pair of FIN and ACK messages from each connection endpoint.
In the most commonly used 3-way handshake, host A sends a FIN to host B, and host B replies with a FIN & ACK. Host B has thus terminated its end and will no longer send data to the other side. Host A successively terminates its own end by sending an ACK message.
The duration the firewall waits for the last ACK is defined by the Last ACK Timeout (s) value in each firewall rule (Firewall > Rule configuration dialogue > Advanced Settings). By default, the firewall waits for the last ACK for 10 seconds and then terminates the session itself. An ACK arriving too late (e.g., because of the long response time of host A or because of network congestion) will not be attributable to an active session and will be dropped by the firewall, thus triggering the message stated above.

Situation 2
Hosts have been observed that respond to a FIN message not only with one but with a second ACK. Again, the second ACK will not be attributable to an active session because the firewall has already terminated it after the first ACK.
Situation 3
Hosts have been observed that continue sending data even though connection termination has already been confirmed by both TCP endpoints. This data will not be attributable to an active session and will be dropped by the firewall, again triggering the message stated above.
Situation 4
Typically, in mainframe systems, hosts might be dependent on an exceptional session lifetime because data is exchanged rarely and idle times in between data exchanges are long. If the maximum idle time is exceeded, the firewall terminates the session between the mainframe computers. Data that the hosts continue to send later, not recognizing that the connection between them has been disrupted, will not be attributable to the firewall and will be dropped, thus triggering the message stated above.
If you observe this message frequently, and at the same time experience network problems of unwanted session termination, the following settings might solve the issue.

Increase Session Timeout of Service objects: See How to Create Service Objects
Increase Last ACK Timeout of firewall rules: See Advanced Access Rule Settings

https://campus.barracuda....-network-troubleshooting/

Lijkt mij sterk maar je zou het kunnen proberen?

[royalt123]

Ik heb altijd zwak gehad voor tcpdump/wireshark dus ik zal men best doen
Als ik andere paratemer moet ingeven dat misschien overzichtelijker maakt zeg het dan maar gerust.

Firewall tcpdump, linux browser opent github.com

code:

[root@Michiels-Home:~]# admintcpdump -i p1.10 src 192.168.10.127 -v
admintcpdump: listening on p1.10, link-type EN10MB (Ethernet), capture size 262144 bytes
11:19:56.305156 IP (tos 0x0, ttl 64, id 14725, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.10.127.49040 > lb-140-82-121-3-fra.github.com.https: Flags [S], cksum 0xd181 (correct), seq 4220193662, win 65520, options [mss 1260,sackOK,TS val 2219334202 ecr 0,nop,wscale 7], length 0
11:19:56.305460 IP (tos 0x0, ttl 64, id 14726, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.10.127.49040 > lb-140-82-121-3-fra.github.com.https: Flags [.], cksum 0x7138 (correct), ack 2292849965, win 65520, length 0
11:19:56.515760 IP (tos 0x0, ttl 64, id 14727, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.10.127.49040 > lb-140-82-121-3-fra.github.com.https: Flags [.], cksum 0x7139 (correct), ack 1, win 65520, length 0
11:19:56.939767 IP (tos 0x0, ttl 64, id 14728, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.10.127.49040 > lb-140-82-121-3-fra.github.com.https: Flags [.], cksum 0x7139 (correct), ack 1, win 65520, length 0
11:19:57.767755 IP (tos 0x0, ttl 64, id 14729, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.10.127.49040 > lb-140-82-121-3-fra.github.com.https: Flags [.], cksum 0x7139 (correct), ack 1, win 65520, length 0
11:19:59.431782 IP (tos 0x0, ttl 64, id 14730, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.10.127.49040 > lb-140-82-121-3-fra.github.com.https: Flags [.], cksum 0x7139 (correct), ack 1, win 65520, length 0
11:20:01.415759 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has Michiels-Home tell 192.168.10.127, length 46
11:20:01.631974 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.127 is-at 00:0c:29:a7:e1:b5 (oui Unknown), length 46
11:20:02.951803 IP (tos 0x0, ttl 64, id 14731, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.10.127.49040 > lb-140-82-121-3-fra.github.com.https: Flags [.], cksum 0x7139 (correct), ack 1, win 65520, length 0
11:20:07.308609 IP (tos 0x0, ttl 64, id 28550, offset 0, flags [DF], proto TCP (6), length 79)
    192.168.10.127.34768 > 209.100.149.34.bc.googleusercontent.com.https: Flags [P.], cksum 0x2a29 (correct), seq 138038558:138038597, ack 3563290165, win 503, length 39
11:20:07.308834 IP (tos 0x0, ttl 64, id 28551, offset 0, flags [DF], proto TCP (6), length 64)
    192.168.10.127.34768 > 209.100.149.34.bc.googleusercontent.com.https: Flags [P.], cksum 0x94c5 (correct), seq 39:63, ack 1, win 503, length 24
11:20:07.308892 IP (tos 0x0, ttl 64, id 28552, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.10.127.34768 > 209.100.149.34.bc.googleusercontent.com.https: Flags [F.], cksum 0x2993 (correct), seq 63, ack 1, win 503, length 0
11:20:07.323023 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.10.127.34768 > 209.100.149.34.bc.googleusercontent.com.https: Flags [.], cksum 0x2992 (correct), ack 2, win 503, length 0
11:20:09.607806 IP (tos 0x0, ttl 64, id 14732, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.10.127.49040 > lb-140-82-121-3-fra.github.com.https: Flags [.], cksum 0x7139 (correct), ack 1, win 65520, length 0
11:20:22.919808 IP (tos 0x0, ttl 64, id 14733, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.10.127.49040 > lb-140-82-121-3-fra.github.com.https: Flags [.], cksum 0x7139 (correct), ack 1, win 65520, length 0
11:20:34.993828 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.10.127 is-at 00:0c:29:a7:e1:b5 (oui Unknown), length 46
11:20:50.055786 IP (tos 0x0, ttl 64, id 14734, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.10.127.49040 > lb-140-82-121-3-fra.github.com.https: Flags [.], cksum 0x7139 (correct), ack 1, win 65520, length 0
11:20:55.175741 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has Michiels-Home tell 192.168.10.127, length 46

Ultraman schreef op vrijdag 27 oktober 2023 @ 10:16:
Misschien een idee om een tcpdump te maken op de client en die te delen?
En als je er een packet capture te maken is op de firewall dan is dat handig.

Hetzelfde tcp dump maar dan met cli curl.

code:

[root@Michiels-Home:~]# admintcpdump -i p1.10 src 192.168.10.127 -v
admintcpdump: listening on p1.10, link-type EN10MB (Ethernet), capture size 262144 bytes
11:22:43.910207 IP (tos 0x0, ttl 64, id 6193, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.10.127.48402 > lb-140-82-121-3-fra.github.com.http: Flags [S], cksum 0xd9c3 (correct), seq 708921784, win 65520, options [mss 1260,sackOK,TS val 2219501807 ecr 0,nop,wscale 7], length 0
11:22:43.910536 IP (tos 0x0, ttl 64, id 6194, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.10.127.48402 > lb-140-82-121-3-fra.github.com.http: Flags [.], cksum 0x6d19 (correct), ack 1958726177, win 512, length 0
11:22:43.910624 IP (tos 0x0, ttl 64, id 6195, offset 0, flags [DF], proto TCP (6), length 115)
    192.168.10.127.48402 > lb-140-82-121-3-fra.github.com.http: Flags [P.], cksum 0x19cf (correct), seq 0:75, ack 1, win 512, length 75: HTTP, length: 75
        HEAD / HTTP/1.1
        Host: github.com
        User-Agent: curl/7.88.1
        Accept: */*
        
11:22:43.959546 IP (tos 0x0, ttl 64, id 6196, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.10.127.48402 > lb-140-82-121-3-fra.github.com.http: Flags [.], cksum 0x6c7a (correct), ack 85, win 512, length 0
11:22:43.961220 IP (tos 0x0, ttl 64, id 31644, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.10.127.54968 > lb-140-82-121-3-fra.github.com.https: Flags [S], cksum 0xd559 (correct), seq 1481508049, win 65520, options [mss 1260,sackOK,TS val 2219501858 ecr 0,nop,wscale 7], length 0
11:22:43.961486 IP (tos 0x0, ttl 64, id 31645, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.10.127.54968 > lb-140-82-121-3-fra.github.com.https: Flags [.], cksum 0x7f1b (correct), ack 4042013130, win 65520, length 0
11:22:44.171683 IP (tos 0x0, ttl 64, id 31646, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.10.127.54968 > lb-140-82-121-3-fra.github.com.https: Flags [.], cksum 0x7f1c (correct), ack 1, win 65520, length 0
11:22:44.583726 IP (tos 0x0, ttl 64, id 31647, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.10.127.54968 > lb-140-82-121-3-fra.github.com.https: Flags [.], cksum 0x7f1c (correct), ack 1, win 65520, length 0
11:22:45.415675 IP (tos 0x0, ttl 64, id 31648, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.10.127.54968 > lb-140-82-121-3-fra.github.com.https: Flags [.], cksum 0x7f1c (correct), ack 1, win 65520, length 0
11:22:47.079701 IP (tos 0x0, ttl 64, id 31649, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.10.127.54968 > lb-140-82-121-3-fra.github.com.https: Flags [.], cksum 0x7f1c (correct), ack 1, win 65520, length 0
11:22:50.375813 IP (tos 0x0, ttl 64, id 31650, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.10.127.54968 > lb-140-82-121-3-fra.github.com.https: Flags [.], cksum 0x7f1c (correct), ack 1, win 65520, length 0
11:22:57.031703 IP (tos 0x0, ttl 64, id 31651, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.10.127.54968 > lb-140-82-121-3-fra.github.com.https: Flags [.], cksum 0x7f1c (correct), ack 1, win 65520, length 0
11:22:59.003680 IP (tos 0x0, ttl 64, id 6197, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.10.127.48402 > lb-140-82-121-3-fra.github.com.http: Flags [.], cksum 0x6c79 (correct), ack 86, win 512, length 0
11:23:10.343694 IP (tos 0x0, ttl 64, id 31652, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.10.127.54968 > lb-140-82-121-3-fra.github.com.https: Flags [.], cksum 0x7f1c (correct), ack 1, win 65520, length 0
11:23:15.463723 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has Michiels-Home tell 192.168.10.127, length 46

[royalt123]

TCP Dump file kunnen maken en downloaden van de firewall.
https://drive.google.com/...dy24zi6P/view?usp=sharing

[deHakkelaar]

@royalt123 , wat geven onder weer voordat je met MTU en MSS gaat pielen?
Text ipv screenshots aub?

code:

file /etc/ssl/certs/ca-certificates.crt

code:

ip link | sed 's/:..:..:.. b/ b/'

code:

ip -4 address

code:

ip -4 route

code:

ip -4 neighbor | sed 's/:..:..:.. / /'

code:

traceroute -n 8.8.8.8

RobIII schreef op vrijdag 27 oktober 2023 @ 09:45:
@Raven Nee, inderdaad, niet het IPv6 deel, maar ik gok dat een MTU wel een goeie is om eens te checken. Heb ook al eens zoiets gehad en toen was 't ook MTU gerelateerd (MSS clamping als ik me goed herinner).

MTU size kun je aanpassen met:

code:

sudo ip link set dev <INTERFACE_NAME> mtu 1200

Valideren met:

code:

ip link show <INTERFACE_NAME>

En MSS size aanpassen met onder:

code:

sudo ip route change default via <ROUTER_IPV4_ADDRESS> advmss 1000

Valideren met:

code:

ip -4 route show default

Herstellen met:

code:

sudo ip link set dev <INTERFACE_NAME> mtu 1500

code:

sudo ip route change default via <ROUTER_IPV4_ADDRESS>

[laurens0619]

maaar je barracuda firewall zegt DROP

Is het niet handiger om daar te gaan kijken?

[mrmrmr]

@royalt123

De tcpdumps zijn niet goed, filter liever op poorten. Met alleen bronpackets zie je maar de helft.

[deHakkelaar]

mrmrmr schreef op vrijdag 27 oktober 2023 @ 13:32:
@royalt123

De tcpdumps zijn niet goed, filter liever op poorten. Met alleen bronpackets zie je maar de helft.

@royalt123 , je kunt naast de poort ook nog extra op het MAC vd client filteren bv:

code:

admintcpdump -ntvi p1.10 tcp port 443 and ether host <MAC_ADDRESS>

EDIT: Ow is het gewone tcpdump commando niet beschikbaar?

[ Voor 7% gewijzigd door deHakkelaar op 28-10-2023 00:23 ]

[royalt123]

@deHakkelaar @mrmrmr

Zie aangepaste dump file op basis van deHakkelaar code.

https://drive.google.com/...VtkOhP5n/view?usp=sharing

[royalt123]

file /etc/ssl/certs/ca-certificates.crt

code:

/etc/ssl/certs/ca-certificates.crt: PEM certificate

ip link | sed 's/:..:..:.. b/ b/'

code:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1300 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 00:0c:29 brd ff:ff:ff:ff:ff:ff

ip -4 address

code:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1300 qdisc fq_codel state UP group default qlen 1000
    inet 192.168.10.127/24 brd 192.168.10.255 scope global dynamic noprefixroute eth0
       valid_lft 34538sec preferred_lft 34538sec

ip -4 route

code:

default via 192.168.10.254 dev eth0 proto dhcp src 192.168.10.127 metric 100
192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.127 metric 100

ip -4 neighbor | sed 's/:..:..:.. / /'

code:

192.168.10.254 dev eth0 lladdr 00:0d:48 STALE
192.168.10.56 dev eth0 lladdr 00:0c:29 STALE
192.168.10.25 dev eth0 lladdr 54:05:db REACHABLE
192.168.10.55 dev eth0 lladdr 00:0c:29 STALE
192.168.10.84 dev eth0 lladdr 48:a2:e6 STALE

traceroute -n 8.8.8.8

code:

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.10.254  0.591 ms  0.685 ms  0.845 ms
 2  192.168.0.1  1.745 ms  1.727 ms  1.711 ms
 3  94.110.64.2  13.673 ms  10.289 ms  12.282 ms
 4  212.65.36.187  15.672 ms  15.657 ms  15.046 ms
 5  81.52.186.121  15.576 ms  15.561 ms  18.677 ms
 6  193.251.241.222  20.866 ms  18.869 ms  20.578 ms
 7  * * *
 8  108.170.241.161  21.242 ms  14.200 ms  12.188 ms
 9  142.251.225.135  12.881 ms 216.239.49.13  18.348 ms 209.85.252.245  17.792 ms
10  8.8.8.8  16.112 ms  17.624 ms  15.950 ms

Voor MTU heb ik getest met 1200 maar gaf geen verschil.
Enkel bij advmss werkt niet voor me, ik krijg dan onderstaande error.

sudo ip route change default via 192.168.10.254 advmss 1000

code:

RTNETLINK answers: No such file or directory

deHakkelaar schreef op vrijdag 27 oktober 2023 @ 13:06:
@royalt123 , wat geven onder weer voordat je met MTU en MSS gaat pielen?
Text ipv screenshots aub?

code:

file /etc/ssl/certs/ca-certificates.crt

code:

ip link | sed 's/:..:..:.. b/ b/'

code:

ip -4 address

code:

ip -4 route

code:

ip -4 neighbor | sed 's/:..:..:.. / /'

code:

traceroute -n 8.8.8.8

[...]

MTU size kun je aanpassen met:

code:

sudo ip link set dev <INTERFACE_NAME> mtu 1200

Valideren met:

code:

ip link show <INTERFACE_NAME>

En MSS size aanpassen met onder:

code:

sudo ip route change default via <ROUTER_IPV4_ADDRESS> advmss 1000

Valideren met:

code:

ip -4 route show default

Herstellen met:

code:

sudo ip link set dev <INTERFACE_NAME> mtu 1500

code:

sudo ip route change default via <ROUTER_IPV4_ADDRESS>

[mrmrmr]

@royalt123

Content
Opvallend is dat content ontbreekt, de pakketten zijn klein. Verder zijn er retransmissions en duplicate ACK.
Er zijn ook nog een aantal 55.65.117.34.bc.googleusercontent.com (34.117.65.55) pakketten. Dat wordt soms gebruikt voor site content. Voor een test kun je blokkeren van third party cookies in de browser tijdelijk uitzetten.

Met F12 kun je zien waar de browser over klaagt.

Netwerk
Als je VM een eigen ipadres heeft, kun je host ipadres (tcpdump -n host 192.168.10.127) gebruiken, zonder src/dst en zonder poortenfilter. De -n zorgt ervoor dat er tcpdump geen queries doet voor ip adressen. Het voordeel van host is dat je alle verkeer ziet, bijvoorbeeld ook arp.

Als je op poorten wil filteren kun je dit gebruiken: icmp and port 53 and port 80 and port 443. Dat is voor icmp (pings), dns en http/https verkeer. De server redirect van http naar https.

tcpdump kan soms het verkeer verstoren door vertragen.

Netwerk en content
Je kan de content van het verkeer decoderen in wireshark met een TLS sleutel van de browser.

Je zou ook kunnen proberen een socks v5 proxy in te stellen in de browser. Die proxy is aanwezig in OpenSSH. Dat kan lokaal of vanaf een andere server. Daarmee is het verkeer niet meer rechtstreeks.

[royalt123]

Ik merk nu ook dat mijn ubuntu met pihole erop niet meer kan bijwerken omdat die ook deels github gebruikt.
Die VM heeft jaren gewerkt zonder issue. Hoe kan nu ineens alle linux nope zeggen tegen github.com en Windows happy going.

Firewall maakt toch geen onderscheid van dat is Linux en dit is Windows.

Het is om zot van te worden

[laurens0619]

Geen onderscheid nee maar het verkeer kan er wel net wat anders uit zien waar een firewall op kan afgaan als false positive.

Mrja (nogmaals) ik snap niet waarom je met al die endpoint analyses bezig bent en niet op de barracuda. De barracuda geeft toch een drop?

Wat ik zou doen als ik jou was is:
- Barracuda Firewall utizetten/ertussen uit halen, lost dat het op?
- Indien ja: Firewall tunen dat die niet meer foutief afgaat. In mijn vorige post heb ik wat barracuda hints gegeven over instellingen die ermee te maken zouden kunnen hebben.

[ Voor 4% gewijzigd door laurens0619 op 30-10-2023 16:07 ]

[royalt123]

Ik heb klein goed nieuws, voordat ik uw bericht zag maar het ligt toch inderdaad aan de firewall.

Ik heb 1 policy met HTTP/S iets aangepast dan werkt het wel. Ik vermoed dat het ergens een bug/fout inzit maar ik moet dat nog verder uitzoeken waarom dat het enkel bij Linux/android niet werkt.

Er wordt geen TLS inspectie gebruikt alsook geen proxy.
Als ik SD-Wan functie afzet dan werkt het wel met alle resterende policy zoals url filter, IPS, Malware protection.

Maar bij die SD-Wan configuratie is erg beperkt.

Voor mij is wel geen oplossing om SD-Wan uit te zetten op HTTPS voor alle netwerk dus zal policy wat verder verfijnen dat enkel github en linux treft.

laurens0619 schreef op maandag 30 oktober 2023 @ 16:06:
Geen onderscheid nee maar het verkeer kan er wel net wat anders uit zien waar een firewall op kan afgaan als false positive.

Mrja (nogmaals) ik snap niet waarom je met al die endpoint analyses bezig bent en niet op de barracuda. De barracuda geeft toch een drop?

Wat ik zou doen als ik jou was is:
- Barracuda Firewall utizetten/ertussen uit halen, lost dat het op?
- Indien ja: Firewall tunen dat die niet meer foutief afgaat. In mijn vorige post heb ik wat barracuda hints gegeven over instellingen die ermee te maken zouden kunnen hebben.

[deHakkelaar]

royalt123 schreef op maandag 30 oktober 2023 @ 11:33:

code:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1300 qdisc fq_codel state UP mode DEFAULT

Waarom een MTU van 1300?
Default staat deze meestal op 1500.

[royalt123]

Probleem ligt aan de firewall maar exact wat kan ik niet zeggen maar het is richting SD-Wan/Auto-nat niet goed werkt om 1 of ander reden met linux/android als source device en destination ook enkel bij github.
Het zal zeer specifiek bug zijn ofzo maar ik heb dan maar workaround toegepast voor nu en in de komende update zal het hopelijk opgelost zijn.