Suppose I have this situation where I wrote a program to poison the ARP cache of 2 devices (let's say A and B), both in the local network to successfully able to MITM from device M. The program runs on device M. When I enable IP forwarding with the command sysctl net.ipv4.ip_forward=1 on device M, HTTP connection from device A to B can be established without any issues, and I am able to see the traffic on device M. But, the same situation where ARP caches are poisoned after I disable the IP forwarding with the command sysctl net.ipv4.ip_forward=0 on device M, HTTP connection can't be established from device A to B. I can see the TCP SYN packet from device A on device M. In my program, after receiving the SYN packet on device M, I modify the src MAC address in the packet with M's MAC address (from A's MAC address) and dst MAC address to B's MAC address (from M's MAC address) and inject it into the network. I don't modify anything from the network layer onwards. I can see the packet at B with new src and dst MACs with TCPdump command, which means the packet gets to the B. But B doesn't respond to that packet, which I can't comprehend why. So, the question is what special does ip_forward=1 does that makes this kind of MITM situation work? To clarify, all the machines are linux. With forwarding enabled on device M, I don't need to modify the MAC addresses in the packets. I just poison the cache and things work fine from there.

My goal is to set up a public IP for a Android Smartphone which is running an "IP Cam" software. The interface can be accessed in local network on (example) 192.168.0.2:8080, but it has no public IP, as it should also work in the 3G network. I know there are services which offer a VPN with static dedicated addresses; the free one I found offers only PPTP with IPv6 (didn't work). The rest of them offer IPv4 for much higher cost than an actual VPS at Host1Plus with the lowest specs, so I went with this. At least I can practice and/or use the VPS for other projects. I followed this tutorial . Now I am at the point where I created a new user, assigned a static VPN Address in the OpenVPN Admin Panel to the account, and logged in with my device. Everything works so far. My android device gets the public IP of the VPS while browsing. I can ping the device's private VPN IP in the ssh terminal of the VPS. What is the next step? I tried [this](https://www.centos.org/docs/4/html/rhel-sg-en-4/s1-firewall-ipt-fwd.html) , but it doesn't really work. I am lost at this point. I never did anything with routes or forwarding. If I enter the public VPS IP right now, I get the openVPN Login Form as before. If I enter [PublicVPSIP]:8080 I get a "Server not reachable etc." error. At the end it should work like this. Android (running some service at port 8080) (VPN IP: 1.2.3.4)
▼
connects via openVPN to my VPS
▼
VPS (running openVPN Server) (Public IP: 123.123.123.123)
▼
Traffic from visitor at 123.123.123.123:8080 should be redirected/forwarded to my android device. (1.2.3.4:8080)

**Goal** Set up NordVPN on my Raspberry Pi and use it as a gateway. **Current set-up** - Raspberry Pi2 running Arch ARM, connected to my router via ethernet cable - NordVPN account - nordvpn installed on my Rpi **Configuration** Here is how I configured my Raspberry. The first step is running nordvpn and selected the desired country. Then I have to take care of the traffic routing. *Enabling IP forwarding:* echo -e 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf *Settig up NAT:*

sudo iptables -t nat -A POSTROUTING -o nordlynx  -j MASQUERADE
sudo iptables -A FORWARD -i nordlynx -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o nordlynx -j ACCEPT

**The problem** At this point, everything is working smoothly and I get an IP that is located in the right country. Unfortunately, most of the services like Netflix, Youtube, and some other websites, won't recognize I'm in another country. I know it's not a NordVPN issue because the Chrome extension works properly. Any ideas?

Can I forward traffic coming into a dummy interface on to another interface? Or is it not a real interface at all even? Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- dummy0 eth6 anywhere anywhere 0 0 ACCEPT all -- eth6 dummy0 anywhere anywhere I want all traffic reaching eth6 to go to dummy0, and all traffic reaching dummy0 to go to eth6. Should I be doing something else really? (I can't use bridges or bonding).

i have a single server which two VM(ubuntu) configured as ubuntu-edge(with frr module for routing - wan side) and ubuntu-fw(for lan side), between these machines there is a virtual internal interface. all the traffic form lan toward fw, and from ubuntu-fw with default route forward to ubuntu-edge. when someone try to reach from behind wan side of the ubuntu-edge to lan side(for example icmp or ssh) cant connect, the tcpdump output is here:

ubuntu@ubuntu-fw:~$ sudo tcpdump -n -i lan host 18.x.x.201
    tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
    listening on lan, link-type EN10MB (Ethernet), snapshot length 262144 bytes
    13:22:43.742256 IP 172.25.4.96 > 18.x.x.201: ICMP echo request, id 60418, seq 4404, length 40
    13:22:43.743299 ARP, Request who-has 172.25.4.96 tell 18.x.x.201, length 46
    13:22:48.861752 ARP, Request who-has 18.x.x.201 tell 18.x.x.1, length 28
    13:22:48.863665 ARP, Reply 18.x.x.201 is-at 74:86:0b:19:fe:c1, length 46
    13:25:42.226903 IP 172.25.4.96 > 18.x.x.201: ICMP echo request, id 60418, seq 4458, length 40
    13:25:42.231842 ARP, Request who-has 172.25.4.96 tell 18.x.x.201, length 46
    13:25:47.236840 IP 172.25.4.96 > 18.x.x.201: ICMP echo request, id 60418, seq 4459, length 40
    13:25:47.237899 ARP, Request who-has 172.25.4.96 tell 18.x.x.201, length 46
    13:25:47.549749 ARP, Request who-has 18.x.x.201 tell 18.x.x.1, length 28

and here is the local route table: ubuntu@ubuntu-fw:~$ ip route show default via 172.24.8.9 dev internal proto static 18.x.x.0/24 dev lan proto kernel scope link src 18.x.x.1 172.24.8.8/30 dev internal proto kernel scope link src 172.24.8.10 the ubuntu-edge, has the route of 172.25.4.96 via bgp dynamic route. what is the problem not forward packet ? by the way packet forwarding is enabled on the both machines. Thanks

I've enabled ip forwarding on a RHEL 7.9 machine, but it's not forwarding any icmp requests. I've set the ip_forward flag cat /proc/sys/net/ipv4/ip_forward 1 /etc/sysctl.conf has been edited to include net.ipv4.ip_forward = 1 and run sysctl -p /etc/sysctl.conf which output net.ipv4.ip_forward = 1 I've disabled the firewall. route -n shows Destination Gateway Genmask Flags Metric Ref Use Iface 5.5.5.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 6.6.6.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 ip addr show gives eth0: inet 5.5.5.1/24 scope global eth0 eth1: inet 6.6.6.1/24 scope global eth1 I can ping 5.5.5.2 and 6.6.6.2 and confirmed with tcpdump that the ping goes out eth0 for 5.5.5.2 and eth1 for 6.6.6.2. When I try to ping through the machine from 5.5.5.2 to 6.6.6.2 and run tcpdump, all I see is tcpdump -i any icmp IP 5.5.5.2 > 6.6.6.2: ICMP echo request IP 5.5.5.2 > 6.6.6.2: ICMP echo request ... come in on eth0. The request is not forwarded out eth1. As far as I can tell, everything is configured correctly to forward ip packets, but it's not working. Is there something else I'm missing?

### Context In my Debian Linux infrastructure, I manage several network interfaces with specific roles. | Interface | Role | Subnet | Description | |-----------|-----------------------|---------------------|-----------------------------------------------------------------------------| | eth0 | Public connection | 192.0.2.0/24 | Used for external public access. | | wg0 | WireGuard VPN | 10.0.0.0/24 | Enables secure communication between machines via the VPN. | | vmbr0 | Bridge for Proxmox | 172.16.0.0/16 | Bridge for virtual machines. | - **Firewall rules**: No iptables/nftables rules are currently applied. All chains have a default policy set to **ACCEPT**. - **Kernel configuration**: IPv4 forwarding is disabled (net.ipv4.ip_forward = 0). --- ### Goal The goal is to strictly limit network communications in the infrastructure: When a computer connects to the VPN via the wg0 interface, it should only be able to communicate with a specific virtual machine located on the vmbr0 bridge. The objective is to ensure complete isolation between interfaces and restrict traffic to this specific use case. --- ### Reproducing the Setup #### WireGuard Configuration (fake information) To replicate the environment, here is a basic WireGuard configuration for two Linux machines: ##### Machine 1: VPN Server (fake information) Interface: wg0 1. **Key generation** (example keys, generated via wg genkey and wg pubkey): - Private key: 9+9N5R5Dje2dmldDtrjQoBb3AFOWhOAyZ9mfWQKn7QY= - Public key: Ci4z9W+n8gfrFRRGZs3DNMHmKk1TFNG9QXGV7zg5OkE= 2. **WireGuard configuration**: (fake information) File /etc/wireguard/wg0.conf:

[Interface]
   PrivateKey = 9+9N5R5Dje2dmldDtrjQoBb3AFOWhOAyZ9mfWQKn7QY=
   Address = 10.0.0.1/24
   ListenPort = 51820

   [Peer]
   PublicKey = YdC5+zMdKj5cRW2WlAv7GDETx+gjZukOmeC+lkJZ8is=
   AllowedIPs = 10.0.0.2/32

3. **Commands to apply**:

sudo wg-quick up wg0
   sudo systemctl enable wg-quick@wg0

##### Machine 2: VPN Client (fake information) Interface: wg0 1. **Key generation**: - Private key: mWjXaRlvJjThhf9ZZpaAWwdY0Puvy0k9fGy7prlzvV8= - Public key: YdC5+zMdKj5cRW2WlAv7GDETx+gjZukOmeC+lkJZ8is= 2. **WireGuard configuration**: File /etc/wireguard/wg0.conf:

[Interface]
   PrivateKey = mWjXaRlvJjThhf9ZZpaAWwdY0Puvy0k9fGy7prlzvV8=
   Address = 10.0.0.2/24

   [Peer]
   PublicKey = Ci4z9W+n8gfrFRRGZs3DNMHmKk1TFNG9QXGV7zg5OkE=
   Endpoint = :51820
   AllowedIPs = 10.0.0.1/24, 172.16.0.0/16, 192.0.2.0/24
   PersistentKeepalive = 25

3. **Commands to apply**:

sudo wg-quick up wg0
   sudo systemctl enable wg-quick@wg0

These configurations establish a simple connection between the VPN server (10.0.0.1) and the client (10.0.0.2). This setup forms the basis for testing the described requirement. #### Bridge

sudo brctl addbr vmbr0
sudo ip addr add 172.16.0.1/16 dev vmbr0
sudo ip link set dev vmbr0 up

### Problem When a client connects to the VPN via the wg0 interface, the following issues are observed: **Access to all interfaces:** Despite different subnets and IPv4 forwarding being disabled, the VPN client can successfully ping all network interfaces, including eth0 and vmbr0. **Packet visibility:** By running tcpdump on each interface (eth0, vmbr0, and wg0), it is observed that the ping packets only traverse the wg0 interface. However, responses are still received when the client pings other interfaces. **Service exposure:** If a service is running on any interface, such as:

python3 -m http.server --bind 192.0.2.1

(bound to the eth0 IP address 192.0.2.1/24), the VPN client has access to this service. **Interface down scenario:** If an interface (e.g., eth0) is brought down using:

ip link set dev eth0 down

the VPN client can still successfully ping the IP address associated with the downed interface and access the running service (e.g., the HTTP server). This behavior persists regardless of the operational state of the interface. **Restricted VM issue:** When adding a virtual machine on the vmbr0 bridge, the VPN client is unable to ping it. (Normal but why can i ping the bridge) ### Request for Assistance Given the above configuration and observed issues: - Why does the VPN client have access to all interfaces (eth0, vmbr0) instead of being restricted by the subnet and the disable forwarding option ? - How can the VPN client still access services or ping IPs on downed interfaces? Any insights or solutions would be greatly appreciated!

I have server A which has a 4-port Network Interface Card, and it is configured to reach the internet via its eth0 where DNS and a gateway and a proxy is specified. I have an *identical* server B with static ip address 192.168.1.2 and I **only** connect its eth1 port to server A's eth1 port (where server A eth1 has static ip 192.168.1.1). How in Linux, RHEL-8.10 specifically, do you configure networking to give server B internet access via (through) server A? As an admin I need a test system (server B) that I can blow up and reboot without affecting users on production server A. But I need internet access on server B to do basic *yum install* stuff conveniently.

I have a Raspberry Pi with an ethernet connection on the end0 interface to the 10.15.16.0/20 network. It has a static IP address on this network at 10.20.30.15. The Pi is also connected to my [Tailscale](https://tailscale.com) tailnet which is available on the tailscale0 interface. Tailscale is configured to accept subnet routes from my tailnet. So the 10.192.168.0/24 network is available through the tailscale0 interface. Tailscale also ensures that this route is added to the routing table. The end0 interface is part of the home zone in Firewalld. tailscale0 is part of the trusted zone. Logged into the Pi, I'm able to reach the 10.192.168.0/24 network. IPv4 and IPv6 forwarding are also enabled on the Pi. **With Firewalld turned off, everything works!** Devices on the 10.15.16.0/20 network are able to reach 10.192.168.0/24 through the Pi (10.20.30.15). With Firewalld on, forwarded traffic is blocked. Ping even helpfully tells me that traffic is being filtered. I think Firewalld has something to do with the message, maybe? Anyway... I tried adding a Firewalld Policy that has home as the ingress zone and trusted as the egress zone, but this did not work. I think that a Policy is the way to go, but how should that look? Here's the policy I wrote

On my Linux machine, I have a UDP server listening on IP 192.168.1.5 port 44123 and an application that sends UDP packets to other devices on the same network, in particular to devices with IP 192.168.1.x port 44124 I want to create an iptables rule to forward all UDP packets from the application to the UDP Server but having difficulties doing so. Example: I wish that the application sends a UDP packet to 192.168.1.10 port 44124 and that it is forwarded to the UDP Server listening on 192.168.1.5 port 44123. Can someone help please? Note: I have set net.ipv4.ip_forward=1

I have two LANs connected with a VPN:

LAN1:192.168.0.0/24  VPN:192.168.2.0/24  LAN2:192.168.10.0/24

The two routers (one on each side of VPN) are running on Debian Linux and IPv4 forwarding is set to 1. I have set static routes: - On LAN1: - On the router: 192.168.10.0/24 via 192.168.2.1 (other side of the VPN) - On clients:  192.168.10.0/24 via 192.168.0.202 (router IP) - On LAN2: - On the router: 192.168.0.0/24 via 192.168.2.2 - On clients:  192.168.0.0/24 via 192.168.10.10 (router IP) On each side, I cleared iptables : systemctl stop fail2ban iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD ACCEPT iptables -F iptables -X iptables -t nat -F iptables -t nat -X iptables -t mangle -F iptables -t mangle -X Results: - From routers, I can ping other router local IP. - From LAN1, I can ping router 2 or any other machine on LAN2. - But from LAN2 (router 2 or client machine), I **CANNOT** ping LAN1 except router 1. ROUTER_1 => ROUTER_2 $ traceroute -n 192.168.10.10 traceroute to 192.168.10.10 (192.168.10.10), 30 hops max, 60 byte packets 1 192.168.10.10 11.254 ms 22.074 ms 22.081 ms ROUTER_1 => LAN2 $ traceroute -n 192.168.10.51 traceroute to 192.168.10.51 (192.168.10.51), 30 hops max, 60 byte packets 1 192.168.2.1 12.293 ms 23.223 ms 23.230 ms 2 192.168.10.51 23.220 ms 23.209 ms 23.199 ms LAN1 => ROUTER_2 $ traceroute -n 192.168.10.10 traceroute to 192.168.10.10 (192.168.10.10), 30 hops max, 60 byte packets 1 192.168.0.202 1.730 ms 1.709 ms 1.775 ms 2 192.168.10.10 13.219 ms 25.229 ms 25.277 ms LAN1 => LAN2 $ traceroute -n 192.168.10.51 traceroute to 192.168.10.51 (192.168.10.51), 30 hops max, 60 byte packets 1 192.168.0.202 2.442 ms 2.358 ms 2.385 ms 2 192.168.2.1 14.530 ms 26.554 ms 26.596 ms 3 192.168.10.51 27.433 ms 27.475 ms 27.519 ms ROUTER_2 => ROUTER_1 $ traceroute -n 192.168.0.202 traceroute to 192.168.0.202 (192.168.0.202), 30 hops max, 60 byte packets 1 192.168.0.202 11.357 ms 22.177 ms 22.123 ms ROUTER_2 => LAN1 $ traceroute -n 192.168.0.91 traceroute to 192.168.0.91 (192.168.0.91), 30 hops max, 60 byte packets 1 192.168.2.2 13.204 ms 24.203 ms 24.189 ms 2 * * * ... 30 * * * LAN2 => ROUTER_1 $ traceroute -n 192.168.0.202 traceroute to 192.168.0.202 (192.168.0.202), 30 hops max, 60 byte packets 1 192.168.10.10 0.107 ms 0.087 ms 0.057 ms 2 192.168.0.202 12.744 ms 24.551 ms 24.522 ms LAN2 => LAN1 $ traceroute -n 192.168.0.91 traceroute to 192.168.0.91 (192.168.0.91), 30 hops max, 60 byte packets 1 192.168.10.10 0.192 ms 0.149 ms 0.131 ms 2 192.168.2.2 13.292 ms 25.037 ms 25.021 ms 3 192.168.0.91 25.006 ms 24.990 ms 24.992 ms What may be going wrong ?  Why router2 CANNOT ping LAN1 ? How can I fix it ?

I have a device DEV1 which should communicate with device DEV3, however in the middle there is DEV2. My understanding is that I need to use IP Forwarding in DEV2 and edit route tables on DEV1 and DEV3. For DEV2 I have enabled IP Forwarding:

-> sysctl net.ipv4.ip_forward

net.ipv4.ip_forward = 1

I can’t set up rest of the things. What should I do to get this to work?

In most cases this is harmless message. In this case, this SSH connection exists solely to forward TCP ports (and it uses a dedicated key which is restricted to only be able to do this), and it should fail if it can't (then service manager will retry connecting until forwarding succeeds). How to force SSH to consider all specified forwardings mandatory and fail hard if either one unsuccessful? The system is Debian 11 and SSH is OpenSSH 8.4p1, if this matters.

According to https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

conf/all/*	  is special, changes the settings for all interfaces

forwarding - BOOLEAN
	Enable IP forwarding on this interface.  This controls whether packets
	received _on_ this interface can be forwarded.

ip_forward - BOOLEAN
	0 - disabled (default)
	not 0 - enabled

	Forward Packets between interfaces.

	This variable is special, its change resets all configuration
	parameters to their default state (RFC1122 for hosts, RFC1812
	for routers)

So, net.ipv4.conf.all.forwarding=0 disables the IPv4 packets forwarding on all interfaces, same as net.ipv4.ip_forward=0 disables the IPv4 packet forwarding on all interfaces. Can anyone, please, explain what's the difference between net.ipv4.conf.all.forwarding and net.ipv4.ip_forward kernel params?

I have hostapd running on two wireless devices in isolated and bridged mode: wlp1s0 is behind the bridge wan, and wlp5s0 is behind the bridge iot. The exact configuration for each bridge is the one described here . wan has the subnet 192.168.2.0/24n and iot the subnet 192.168.3.0/24. I'm trying to setup SSDP forwarding from wan to iot so I can connect to Sonos players on iot using a controller on wan. I'm following this guide . Note that it's written with two different VLANs in mind but I assume the same should work for two different bridges. I have thus set up an igmpproxy instance with the configuration

phyint wan upstream   ratelimit 0 threshold 1
phyint iot downstream ratelimit 0 threshold 1

For testing purposes I have disabled packet filtering entirely between the two bridges on the firewall. I would expect this setup to be enough, but the controller on wan cannot see the players on iot. The players do register correctly to the IGMP proxy (192.168.3.29 is one of the players):

igmpproxy: SENT Membership query   from 192.168.3.1     to 224.0.0.1
...
igmpproxy: RECV V2 member report   from 192.168.3.29    to 239.255.255.250
igmpproxy: Should insert group 239.255.255.250 (from: 192.168.3.29) to route table. Vif Ix : 1
igmpproxy: Updated route entry for 239.255.255.250 on VIF #1

I can check using TCP dump that the controller indeed sends SSDP packets (192.168.2.67 is the controller):

> tcpdump -i wan port 1900
...
16:16:07.600003 IP 192.168.2.67.49628 > 239.255.255.250.ssdp: UDP, length 202
16:16:07.600003 IP 192.168.2.67.49628 > 255.255.255.255.ssdp: UDP, length 202
...

and it seems igmpproxy is receiving these correctly:

igmpproxy: Vif bits : 0x00000002
igmpproxy: Setting TTL for Vif 1 to 1
igmpproxy: Adding MFC: 192.168.2.67 -> 239.255.255.250, InpVIf: 2
...
igmpproxy: Current routing table (Insert Route):
igmpproxy: -----------------------------------------------------
igmpproxy: #0: Src0: 192.168.2.67, Dst: 239.255.255.250, Age:2, St: A, OutVifs: 0x00000002, dHosts
igmpproxy: -----------------------------------------------------

I am not seeing these packets being forwarded with tcpdump though. I would expect some packet on iot with destination the IPs that got registered for multicast on 239.255.255.250 (so the sonos player in particular). Hence I assume this is what causes the discovery to fail. Why am I not seeing the SSDP packets being forwarded ? What should I change for the Sonos controller to discover the players through SSDP ?

I want to ask about network options on virt-manager. I used to have the options shown in the given picture host device eth0 : macvtap host device wlan0 : macvtap and I would see the eth0 and wlan0 interfaces when I want to forward NAT to eth0 in virt-manager when adding a new virtual network. I'm on Debian 11 after installing qemu kvm virt-manager and the extras and everything related sudo apt install qemu-kvm libvirt-clients libvirt-daemon-system bridge-utils libguestfs-tools genisoimage virtinst libosinfo-bin virt-manager libspice-client-glib-2.0 libspice-client-gtk-3.0 qemu-utils sudo adduser $USER libvirt-qemu sudo adduser $USER libvirt sudo modprobe macvtab macvlan but still after restart, the macvtap options are not there whatever I do. Of course, I enabled macvtab in the kernel and even if I add it using: ip link add link eth0 name macvtap0 type macvtap mode bridge/or vepa / or passthrough still doesn't show. eth0 and wlan0 options or other interfaces like proton0 [created by ProtonVPN] or tun0 created by OpenVPN do not show up when I try to create a new virtual network on virt-manager and forward NAT to any of these interfaces. What's the problem here? How can I get these options again?

I'm trying to use ssh -Y/X ManjaroHost from my Mac, but get "X11 Forwarding request failed". I've searched for the solution for two weeks, and have tried many methods suggested by similar posts. It would be a great help to point out my mistakes! Here are some experiments I've done. To make everything clear, I always ssh from HostA to HostB. HostA is the X server and ssh client, while HostB is the ssh server. Experiment 1 HostA: My Macbook. HostB: Another Linux cluster. It works, perfectly, GUI windows will popup on my Mac. In HostA, echo $DISPLAY --> /private/tmp/com.apple.launchd.6AxM1TJrRh/org.xquartz:0 In HostB, echo $DISPLAY --> localhost:10.0 So I think my Mac end works good. Experiment 2 HostA: My Macbook. HostB: Manjaro Linux Lenovo. HostA: DISPLAY is /private/tmp/com.apple.launchd.6AxM1TJrRh/org.xquartz:0 HostB: DISPLAY is empty. Here is the debug information from ssh -Yvvv

...
...
...
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Requesting authentication agent forwarding.
debug1: Sending environment.
debug1: channel 2: setting env LC_TERMINAL_VERSION = "3.4.15"
debug1: channel 2: setting env LANG = "en_US.UTF-8"
debug1: channel 2: setting env LC_TERMINAL = "iTerm2"
debug1: mux_client_request_session: master session id: 2
Last login: Wed Nov  9 13:55:34 2022 from 192.168.0.194
X11 forwarding request failed

Experiment 3 In case this is because of some internet setup, I tried to ssh -Y 127.0.0.1 in Manjaro Linux Lenovo HostA = HostB = Manjaro Linux Lenovo HostA: DISPLAY = :0 HostB (after ssh): DISPLAY is empty. The debug information from ssh -Yvvv is

ssh -Yvvv  127.0.0.1                                                           
...
...
...
debug1: client_input_hostkeys: no new or deprecated keys from server
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: x11_get_proto: /usr/bin/xauth  list :0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 1
debug3: send packet: type 98
debug2: fd 3 setting TCP_NODELAY
debug3: set_sock_tos: set socket 3 IP_TOS 0x48
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: receive packet: type 100
debug2: channel_input_status_confirm: type 100 id 0
**X11 forwarding request failed on channel 0**
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Wed Nov  9 14:43:39 2022 from 127.0.0.1

It still shows "X11 forwarding request failed on channel 0" Here is my Manjaro sshd_config file

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost no
AllowTcpForwarding yes
AllowAgentForwarding yes
PermitRootLogin	yes

ssh_config file

HOST *
    #ServerAliveInterval 60
    #ServerAliveCountMax 5
    ForwardAgent yes
    ForwardX11 yes
    #ControlPersist yes
    ControlMaster auto
    ForwardX11Trusted yes

My Mac ssh_config file

HOST *
    ServerAliveInterval 60
    ServerAliveCountMax 5
    ForwardAgent yes
    ForwardX11 yes
    ControlPersist yes
    ControlMaster auto
    ControlPath ~/.ssh/master-%r@%h:%p
    ForwardX11Trusted yes
    identityfile ~/.ssh/id_rsa_gmail

I think I've tried everything I can, but fail to figure out the issue. Appreciated if someone could help!

i am trying to do something , but i cant get it to work After at least 4-5 hours of research and trying , its time for help I want to connect to a second remote machine trough a primary remote machine my setup is like that -> "Home1" windows desktop machine with SSH server -> "HOME" router with opened port to "Home1" SSH server -> internet -> "REMOTE" router with port opened to SSH server to "Remote1" -> "Remote1" on the same LAN as "Remote2" -> Http Server on port 1080 on "Remote1" -> Http Server on port 80 on "Remote2" -> Empty IPTABLE and policy set to ACCEPT on "Remote1" what is working right now : - i can connect to SSH console on "Remote1" - launch reverse SSH tunneling from "Remote1" To "Home1" -> ssh -fN -R 1080:localhost:1080 user@HOMEIP - i can acces "Remote1" http server from "Home1" by typing 127.0.0.1:1080 in my browser SO FAR everything is OK but if i try to do ssh -fN -R 80:localhost:80 user@HOMEIP then iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.1.1:80 iptables -t nat -A POSTROUTING -j MASQUERADE i can never get acces to "Remote2" http server i get an error on the "Remote1" console everytime i try to acces it thru my browser on "Home1" connect_to localhost port 80: failed. i am sure that "Remote2" is up and running , because it is actually my ISP router and i want to acces it to open new ports (interface acces is only possible from LAN and locked from WAN) (i have 3 hours of road to "REMOTE" and no one on site for weeks) also tried many permutation of different settings and nothing seem to work THANKS

I have a DigitalOcean droplet into which I'm attempting to clone a repo from Github. This works fine on my local machine, and I've been following the guide from Github here: I had to manually enable SSH Agent with eval $(ssh-agent -s) on the server but as far as I can tell agent forwarding is not occurring since I get no access using ssh -T git@github.com from the server, the debug output from ssh -v git@github.com is:

OpenSSH_8.2p1 Ubuntu-4ubuntu0.5, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to github.com [140.82.121.3] port 22.
debug1: Connection established.
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa_sk type -1
debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: identity file /root/.ssh/id_ed25519_sk type -1
debug1: identity file /root/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /root/.ssh/id_xmss type -1
debug1: identity file /root/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.5
debug1: Remote protocol version 2.0, remote software version babeld-181fb29f
debug1: no match: babeld-181fb29f
debug1: Authenticating to github.com:22 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC:  compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC:  compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM
The authenticity of host 'github.com (140.82.121.3)' can't be established.
ECDSA key fingerprint is SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'github.com,140.82.121.3' (ECDSA) to the list of known hosts.
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /root/.ssh/id_rsa 
debug1: Will attempt key: /root/.ssh/id_dsa 
debug1: Will attempt key: /root/.ssh/id_ecdsa 
debug1: Will attempt key: /root/.ssh/id_ecdsa_sk 
debug1: Will attempt key: /root/.ssh/id_ed25519 
debug1: Will attempt key: /root/.ssh/id_ed25519_sk 
debug1: Will attempt key: /root/.ssh/id_xmss 
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ecdsa_sk
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: Trying private key: /root/.ssh/id_ed25519_sk
debug1: Trying private key: /root/.ssh/id_xmss
debug1: No more authentication methods to try.
git@github.com: Permission denied (publickey).

In the local machine I have created a config entry for the server IP:

Host x.x.x.x
    ForwardAgent yes

I have also edited the sshd_config file on the server to:

AllowAgentForwarding yes

I have added the local key on my local machine using: ssh-add ~/.ssh/id_rsa I don't know what else to do, and I've been beating my head against this for hours. (I've read everything I can find but nothing helped.)

I'm building a captive portal (yeah, just-another ;) ) and now I'm trying to handle the core feature, the iptables rules.  Based on ipset I have a list of valid mac-addresses with name allow-mac.  So this is the current config (stripped to the problem itself):

echo 1 >/proc/sys/net/ipv4/ip_forward

ipset create allow-mac hash:mac counters
ipset add allow-mac XX:XX:XX:XX:XX:XX

IPT="/usr/sbin/iptables"

WAN="eth0"
LAN="eth1"

$IPT -P FORWARD DROP
$IPT -t nat -A POSTROUTING -o $WAN -j MASQUERADE
$IPT -I FORWARD -i $LAN -m set --match-set allow-mac src -j ACCEPT

This should work but it didn't! so, if I change the default FORWARD chain to ACCEPT and change the rule to the inverse:

$IPT -P FORWARD ACCEPT
$IPT -I FORWARD -i $LAN -m set ! --match-set allow-mac src -j DROP

I have the desired result, and only clients with known MAC-address in list can forward. So my question, why is it not working in the first setup? And my second missing feature is, if the counters module is already added, but now the "upload" traffic from client is counted, how can (in a separated counter) I also count the download traffic as well?