I have set up a network in EVE-NG (6.2.0-4-Community) with the following configuration (all using a 24-bit mask):
WebServer: 10.10.0.10 (FreeBSD)
Net5: 172.31.5.10 (FreeBSD)
Net0: 172.31.0.10 (Debian)
RT-01: e1/172.31.0.2, e2/172.31.5.1 (VyOS)
RT-02: e3/172.31.5.2, e4/172.31.10.1, e5/10.10.0.1 (VyOS)
From WebServer, Net5, and Net0, I can access websites like Google using w3m.
# It looks like Palo Alto is not running, but it is connected to the physical Palo Alto via the surrounding bridge (vlan 10-30).
My final goal is to enable HTTP communication along the green path, but before that, I tested the purple path and successfully accessed the WebServer via HTTP.
Next, I tested the red path. Ping works, but HTTP traffic does not.
When capturing HTTP packets on Net0’s e0 interface, I see the following flow:
Net0 → Web syn
Net0 ← Web syn, ack
Net0 → Web ack
Net0 → Web GET
Net0 → Web ack (retransmission)
Net0 → Web ack (continued retransmissions)...
However, when capturing packets on RT-01’s eth1, I only see:
Net0 → Web syn
Net0 ← Web syn, ack
No packets appear after this.
What could be blocking HTTP communication?
Running on Proxmox CE (proxmox-ve: 8.4.0 (running kernel: 6.8.12-10-pve))
root@eve-ng:~# eve-info
Thu May 15 12:04:24 PM UTC 2025
---------------Packages Installed----------------
ii eve-ng 6.2.0-4
ii eve-ng-dynamips 6.0.1-5
ii eve-ng-pro-guacamole 6.2.0-6
ii eve-ng-qemu 6.0.1-0
ii eve-ng-schema 6.0.1-0
ii eve-ng-vpcs 6.1-eve-ng
---------------Hostname--------------------------
Static hostname: eve-ng
Virtualization: kvm
Operating System: Ubuntu 22.04.5 LTS
Kernel: Linux 6.7.5-eveng-6-ksm+
Architecture: x86-64
---------------Disk Usage------------------------
Filesystem Size Used Avail Use% Mounted on
tmpfs 6.3G 1.7M 6.3G 1% /run
/dev/mapper/ubuntu--vg-ubuntu--lv 502G 271G 210G 57% /
tmpfs 32G 0 32G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 32G 0 32G 0% /run/qemu
/dev/sda2 2.0G 322M 1.5G 18% /boot
tmpfs 6.3G 4.0K 6.3G 1% /run/user/0
---------------CPU Info--------------------------
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 48 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Vendor ID: AuthenticAMD
Model name: AMD Ryzen 7 8845HS w/ Radeon 780M Graphics
CPU family: 25
Model: 117
Thread(s) per core: 1
Core(s) per socket: 16
Socket(s): 1
Stepping: 2
BogoMIPS: 7585.74
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm rep_good nopl cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw perfctr_core ssbd perfmon_v2 ibrs ibpb stibp ibrs_enhanced vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt
xsavec xgetbv1 xsaves avx512_bf16 clzero xsaveerptr wbnoinvd arat npt lbrv nrip_save tsc_scale vmcb_clean flushbyasid pausefilter pfthreshold vgif vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid overflow_recov succor fsrm flush_l1d arch_capabilities
Virtualization features:
Virtualization: AMD-V
Hypervisor vendor: KVM
Virtualization type: full
Caches (sum of all):
L1d: 1 MiB (16 instances)
L1i: 1 MiB (16 instances)
L2: 8 MiB (16 instances)
L3: 256 MiB (16 instances)
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0-15
Vulnerabilities:
Gather data sampling: Not affected
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Retbleed: Not affected
Spec rstack overflow: Mitigation; Safe RET
Spec store bypass: Vulnerable
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Vulnerable, IBPB: disabled, STIBP: disabled, PBRSB-eIBRS: Not affected
Srbds: Not affected
Tsx async abort: Not affected
---------------Memory Info-----------------------
total used free shared buff/cache available
Mem: 62Gi 12Gi 48Gi 6.0Mi 2.1Gi 49Gi
Swap: 15Gi 0B 15Gi
---------------Nic Info--------------------------
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master pnet0 state UP mode DEFAULT group default qlen 1000
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master pnet1 state UP mode DEFAULT group default qlen 1000
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master pnet2 state UP mode DEFAULT group default qlen 1000
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master pnet3 state UP mode DEFAULT group default qlen 1000
---------------IP Info---------------------------
● State: carrier
Online state: unknown
May 15 05:53:16 eve-ng systemd-networkd[738]: vunl0_1_3: Lost carrier
May 15 05:53:16 eve-ng systemd-networkd[738]: vunl0_1_4: Lost carrier
May 15 05:53:16 eve-ng systemd-networkd[738]: vunl0_1_5: Lost carrier
May 15 05:53:16 eve-ng systemd-networkd[738]: vunl0_1_6: Lost carrier
May 15 05:53:16 eve-ng systemd-networkd[738]: vunl0_1_7: Lost carrier
May 15 05:53:16 eve-ng systemd-networkd[738]: vunl0_1_8: Lost carrier
May 15 05:53:45 eve-ng systemd-networkd[738]: vunl0_10_0: Lost carrier
May 15 05:53:46 eve-ng systemd-networkd[738]: vunl0_10_1: Lost carrier
May 15 05:54:13 eve-ng systemd-networkd[738]: vunl0_12_0: Lost carrier
May 15 05:54:14 eve-ng systemd-networkd[738]: vunl0_12_1: Lost carrier
---------------Bridge Info-----------------------
pnet0 8000.bc24116aa1ae no eth0
pnet1 8000.e6ea6ff1b148 no eth1
pnet2 8000.f2413142becf no eth2
pnet3 8000.46311da6b96f no eth3
pnet4 8000.a20be6f6256c no
pnet5 8000.aa1ae5aeae65 no
pnet6 8000.365956c69db3 no
pnet7 8000.de8ca0d1d81f no
pnet8 8000.7afb5dce473f no
pnet9 8000.7e8a40746c1d no
---------------H/W Accel-------------------------
INFO: /dev/kvm exists
KVM acceleration can be used
---------------Service Info----------------------
-------------------------------------------------
--------------Guacamole--------------------------
● guacd.service - LSB: Guacamole proxy daemon
Loaded: loaded (/etc/init.d/guacd; generated)
Active: active (running) since Thu 2025-05-15 04:26:29 UTC; 7h ago
--------------Tomcat-----------------------------
Unit tomcat8.service could not be found.
--------------Mysql------------------------------
● mysql.service - MySQL Community Server
Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2025-05-15 04:26:30 UTC; 7h ago
--------------Apache-----------------------------
● apache2.service - The Apache HTTP Server
Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/apache2.service.d
└─local.conf
Active: active (running) since Thu 2025-05-15 04:26:30 UTC; 7h ago
No HTTP Response Despite Successful Ping in EVE-NG
Moderator: mike
-
- Posts: 2
- Joined: Thu May 15, 2025 10:35 am
No HTTP Response Despite Successful Ping in EVE-NG
You do not have the required permissions to view the files attached to this post.
-
- Posts: 358
- Joined: Thu Mar 29, 2018 4:19 pm
Re: No HTTP Response Despite Successful Ping in EVE-NG
can be several things try to bisect your lab in parts and check each part.
-
- Posts: 2
- Joined: Thu May 15, 2025 10:35 am
Re: No HTTP Response Despite Successful Ping in EVE-NG
I identified the issue.
The default gateway for Net0 was set to Palo Alto.
Net0 → PA → RT-01 → RT-02 → WebServer syn
Net0 ← -- ← RT-01 ← RT-02 ← WebServer syn, ack (does not pass through PA)
Net0 → PA ack (PA detects an anomaly and filters it because it received ack without first receiving syn, ack)
Net0 → PA Web GET (same as above)
Added the following settings to Palo Alto’s zone protection (allowing asymmetric routing):
I assumed Palo Alto wasn’t involved.Thank you.
PaloAlto : https://knowledgebase.paloaltonetworks. ... lang=en_US
The default gateway for Net0 was set to Palo Alto.
Net0 → PA → RT-01 → RT-02 → WebServer syn
Net0 ← -- ← RT-01 ← RT-02 ← WebServer syn, ack (does not pass through PA)
Net0 → PA ack (PA detects an anomaly and filters it because it received ack without first receiving syn, ack)
Net0 → PA Web GET (same as above)
Added the following settings to Palo Alto’s zone protection (allowing asymmetric routing):
Code: Select all
set deviceconfig setting tcp asymmetric-path bypass
set deviceconfig setting session tcp-reject-non-syn no
PaloAlto : https://knowledgebase.paloaltonetworks. ... lang=en_US