@bmffsc said in redirect wan ip requests to lan ip address: reaching through http://212.252.119.3:8092/OurApp/ Horrible setup! Use a fqdn that resolves to this IP.. Now outside users can get to it via http://something.domain.tld:8092/ourapp where that resolves to 212.x.x.x. your public IP. And internally it resolves to 192.168.1.100 or whatever you local IP of that server is. So the same bookmark works be it they outside or inside.

I had this same issue with my Zyxel GS1900-24e managed switch. It did not appear in the DHCP leases list, yet it was working like a charm. But I did not know its IP and thus couldn't connect to its GUi for maintenance, and I did not like that. Just for the record, and it may help someone after me with the same issue, here's what I did: I unplugged the cable between the pfSense router (in my case, an SG-1100) and the switch. On my Mac I configured static IP 192.168.1.2 with subnet mask 255.255.255.0 and then connected to 192.168.1.1 and there it was: the html GUI page of the switch. If this does not work, reset the switch by pressing the tiny reset button at the front using a paperclip or something like it for some time. Then I configured the switch to use DHCP (in Maintenance > System > IP > Mode: DHCP). When that was done I configured the LAN on my Mac to use DHCP again and plugged the cable between router and switch back in. After restarting the switch its IP appeared in the DHCP leases list on the Netgate SG-1100.

@fishbone222 said in AddTrust External CA Root certificate has expired! Cannot update packages..: https://forum.netgate.com/topic/154033/unable-to-download-available-package-list-cert-expired That's useful thanks, worked for me! Seems problem is fixed now.

Sorry for the late post but wanted to close it out here in the rare case someone searches for the issue. I gave up on Dlink support and this device. It should have auto negotiated and been fine. My first solution was to use a tplink ac740 in wifi bridge mode, then connect the hub to the ac740 using an Ethernet cable. Since then I added a Ubiquiti 24 port poe switch and have zero issues with the Honeywell hub when going through a different switch. Isn't IOT wonderful!

@laynakail said in SYN_SENT:CLOSED & CLOSED:SYN_SENT: CLOSED:SYN_SENT That just means the syn was sent, but not reply was received.. I can send a syn anywhere, but if they don't answer the state will never be opened.. Sniff on your outbound traffic when you try and make a connection - you see the syn go out, do you ever see a syn,ack back? from closeds:syn_sent that would be a no.. example... I try and open connect to say 1.1.1.1 on port 666.. [image: 1590753260273-closedsyn.jpg] So pfsense sent the syn trying to connect to 1.1.1.1 on port 666.. But no answer.. So the states are closed:syn_sent Here is sniff showing syns being sent - but nothing coming back. [image: 1590753666420-synsent.jpg] Also vs posting some ascii art, how about a screenshot of what your trying show.. Are those suppose to be your wan rules? Show them in a simple screenshot.. .So much easier to decipher If those are you wan rules - they have nothing to do with talking to some website.. Those would only be port forwards to something inside your network or allowing traffic direct to pfsense wan IP, or allowing something through to a routed public network, etc. I assume its your wan because you look to have bogon on there..

I believe it defaults to 10.0.8/24 - this is fine.. Any network that is unlikely to overlap either your remote user or your sites network is fine.

I was able to install Pfsense via a laptop onto the hard drive and install the hard drive back in to the host computer and it worked. I used the same media on both devices, not sure what would have caused this issue.

If you're on 2.4.4 and installed or updated packages you would have pulled down packages designed for 2.4.5 and the newer PHP and/or FreeBSD. Can you get it to update to 2.4.5?

Not exactly. The problem is once again NIC driver weirdness with the netmap kernel device support in FreeBSD. That message is informative telling you the host ring queue exposed by the netmap device is full. It would have been later emptied and all would be well.

I thought a fiber-to-RJ45 converter will work. I didn't know that the ISP router contains a modem, which is required for ONT login. I am ashamed. Please close this thread.

Changed the NIC to an Intel ET adapter from a Marwell Yukon. No packetloss and so far still a stable connection. Looks like the Marwell driver has a memory leak.

@donuts It shouldn't. But that's why you should know what's normal, before trying to find out what's failed.

@mjimlay The same way as you'd route over any IP interface. Go into System>Routing and go from there. You might also have to consider firewall filters.

Well, I think that there is two solutions, depending of the objective: Objetive 1.- Local Server <---> Remote Server Create a Phase 2 and configure: Local Network: Address > 10.10.10.10 NAT/BINAT translation: Address > 192.168.20.1 Remote Network: Address > 20.20.20.20 Only the Host that We put in Local Network can go through the VPN to the Host that We put in Remote Network. We also need add a Firewall Rule (Firewall > Rules > IPsec) that permit the traffic from 20.20.20.20 to 192.168.20.1 The Local Server can connect to Remote Server through the IP 20.20.20.20 and the Remote Server can connect to Local Server through the IP 192.168.20.1 Objetive 2.- Local LAN <---> Remote LAN Create a Phase 2 and configure: Local Network: Network > 10.10.10.0/24 NAT/BINAT translation: Network > 192.168.20.0/24 Remote Network: Network > 20.20.20.0/24 All de Hosts in the network that We put in Local Network can go through the VPN to the Hosts in the network that We put in Remote Network. We also need add a Firewall Rule (Firewall > Rules > IPsec) that permit the traffic from 20.20.20.0/24 to 192.168.20.0/24 In this situation, the NAT is done Host to Host, that is: 10.10.10.1 > 192.168.20.1 10.10.10.2 > 192.168.20.2 10.10.10.3 > 192.168.20.3 10.10.10.4 > 192.168.20.4 And the Remote Hosts can reach the Local Hosts by the corresponding NATed IP (192.168.20.x) I think that this is correct. If It is not correct, please, tell me. We are thinking that all config is correct in the Remote FW. Regards, Ramsés

@NogBadTheBad Yes, understood - I just tweaked it a bit to confirm the root cause of the issue

@Gertjan I'm sorry. I'm not understanding what you wrote. Unbound has forwarding disabled so it should be doing it's own resolving. I'm not sure what else you would want me to detail. Network Interfaces: LAN+All VLANS Outgoing Network Interfaces: LAN + OPT1 DNSSEC: ON Forwarding: OFF DHCP Registration: ON Static DHCP: ON OpenVPN Clients: ON As for the version issue. Just refreshing changes whether it says I'm on the latest or if there is a new version available. If i keep refreshing it switches back and forth. I'm assuming that is because sometimes there is response on the WAN and sometimes on the OPT1, however, I would expect it to either be correct in showing 2.4.5 or just fail. Since I've disabled OPT1 it's been correct every time I refresh. I know there is some kind of DNS issue on the AT&T side. I'm facing 2 issues that I see: Why DNS queries are sent out of OPT1 when the routing is still going out of WAN. Why DNS is failing and returning the wrong info over the DSL where it shows google.com at 192.168.1.254 and the Arris modem is trying to pass off the certificates. I assume that is because that is what the modem is sending. My best guess at this moment is that the DSL modem has been reset and is intercepting all of the traffic because it's waiting for a user to log in and activate. That's the only thing I can think of that would cause it to behave in this way. (I HATE DSL). I suppose what I need to know, then, is how to limit DNS queries to go out the interface that is the current route. I don't want queries going out OPT1 when routing has the data going over the WAN.