Messages

> Are you sure, that the modem is in bridge mode? Or is it just forwarding any traffic to OPNsense WAN? Which IP do you get on OPNsense WAN?

I am sure. I set the modem to transparent bridging with vlan-201, and the WAN IP according to opnsense after disabling and re-enabling the WAN interface changed from a private network to a public network. The WAN IP address according to opnsense starts with 174 and the real.public.ip.address starts with 174 as well, but they are different numbers. Something like 174.1.2.3 opnsense WAN and 174.4.5.6 real.public.ip.address. I'm using the IP of real.public.ip.address to try to connect.

> So you get the requests to the NAS. But it is not responding.

Yeah, this makes a lot of sense to me, but I don't think there's a firewall running on that machine. sudo ufw status returns Status: inactive

I'm not aware of any other firewall software running on it.

... 5 minutes later ...

Welp, this comment gave me pause as I realized that I was running a VPN on that server. Tore the VPN down and then it started working. I have some gibberish to sort out now, but at least I have a solution. Thank you for your help!

Same result, a hanging network request, if I try to navigate to http://real.public.ip.address from my phone.

Edit: And if I curl the local IP of "nas," it works fine, so I don't think the http/https server is misconfigured. It seems to be either some kind of ISP side weirdness like cgnat or a misconfiguration of opnsense. The latter seems like the most likely.

More Edit: Forgot to mention that I don't see any access or error logging in the http server when I try to hit it from outside. The only evidence I have that the traffic is making it through the firewall are those lines I see in the output of tcdump. Well, and the live view of the firewall appears to show the same.

Network Devices:
Fiber from service provider to Q1000K modem/router configured as a transparent bridge with vlan-201. I don't really understand what the vlan-201 means, but when I tried the setting that didn't set any vlan such as vlan-201, nothing worked.
Ethernet to Opnsense 26.1
Ethernet to linux box "nas" listening on http and https

I am somewhat confused about whether or not CGNAT is at play here. The fact that I get any packets through leads me to believe that it's not CGNAT. But I do see two different IPs when I check the WAN interface in opnsense and compare it to the response from icanhazip.com or "my ip" in a search engine.

I'll only use the one from icanhazip.com or "my ip" but I'll write it as "real.public.ip.address"

I am testing the port forwarding using a cloud box. I run curl --connect-timeout 5 -vvvvv http://real.public.ip.address

At the same time, I am running on the nas the command `tcpdump -i <device> | grep public.ip.cloud.box` displays entries such as:
12:06:00.827255 IP public.ip.cloud.box>.33536 > nas.http: Flags S, seq 3344993040, win 64240, options [mss 1424,sackOK,TS val 2064031373 ecr 0,nop,wscale 7], length 0

Edit: The Flags are in square brackets but that causes formatting issues so I took out the brackets.

Which seems to indicate to me that at least some of the traffic is making it through the firewall and to the nas. I don't see any outgoing traffic, though. I see other bidirectional traffic in tcpdump so I'm interpreting this as the packets either never making it to the https server or the https server is just dropping them for some reason.

Likewise, tcpdump results filtered for the destination IP on the cloud box appear identical.

I altered the binding for the opnsense web server to only bind on the LAN bridge.

I created a Destination NAT rule:
Protocol: TCP/UDP
Destination: WAN address
Destination Port: https
Redirect Target IP: local.ip.address.nas
Redirect Target Port: https
Firewall rule: I've tried all of these. Register rule is the current setting and it results in tcpdump identifying incoming packets from public.ip.cloud.box.

If I try to curl to real.public.ip.address from opnsense, I get an instant failed to connect message, so I guess I can't hairpin like that.

I'm at a loss for what else to try here.

Thanks, iMx. I did figure that out last night. The automated backups are a lifesaver.

Hi there. I was following this thread: https://forum.opnsense.org/index.php?topic=26638.0 trying to see if I could fix my slow throughput.

Hardware: O-Droid H3+ 32GB RAM with 4 port extended Realtek NIC

They didn't actually say to uncheck the "disable hardware checksum offload", so I'm not sure why I did, but when I did, I broke the system such that I can't get into it anymore except directly via command line. Stupidly, I have not made a backup yet (very early in getting things working, so didn't consider myself to have a "good" config.")

I would rather not have to start from scratch, but that's obviously an option. I'm in /conf/config.xml but I don't see anything that appears relevant to this setting.