No. This is my home network.

I'm going to try to flash to newer firmware and restart everything from scratch in the router over the next ~15 minutes. If nothing changes, I'm assuming it's not router.

(Edit) firmware *is* the latest version, resetting router to factory defaults.

Set up router to bare basics. Set a static IP to the server (192.168.1.2)

Connection times out on everything I try to do to it. Including ssh -vvv to 96.46.21.187.

Remote Management works fine on port 8181. Nothing else does.

Call the ISP? Or are you technically not allowed to port forward? I would think if you are paying for a fiber line you can do pretty much whatever the fuck you want with it. Who runs the line? Verizon Fios?

Last resort here. The new ISP *sucks*, and I was with my old ISP specifically to not deal with them.

Yeah, these guys think residential lines are *only* for web browsing. They baaaaad.

Nope. Local telecom company that leases fiber from our local utility district.

If it wasn't for the retarded shit related to servers with these guys, they could put Verizon FIoS to shame. But they go FULL FUCKING RETARD in many aspects since the owner doesn't really know wtf he is doing - this is why I wasn't dealing with them before.

I'm going to keep fiddling, but I'm having difficulty believing it's my router when, two weeks ago, this router worked perfectly. I'm also having difficulty believing that it is the server, 'cause I've dealt with Linux servers for over 15 years ('94? '95? '96? Somewhere in there.) so...

If it works inside, doesn't work outside, and the ISP is a bitch who thinks they can control what you run, it is probably their fault.

That's the bad news.

The good news is, if it is a local telecom that rents the fiber, there is probably an easy way around it. The trick will be finding it.

Figure out which ports some of those fancy security systems are running on, and tell the local ISP you need them open. Then run everything through those. Or hell even make up some ports and tell them your security system needs them open. Or some other legitimate need for open inbound ports, as that was the first thing that popped in my head.

I'm just trying to get this setup for when I finish my move across the state in a week. I won't have any relation to them very shortly.

Drives me nuts that I can't thoroughly test any of this /before/ I finish my move. I /hate/ being unprepared like that.

If pf isnt working from the inside, its not the ISP's fault.

Everything works fine from 192.168.* addresses, Rev. Trust me on that, I've tested it extensively.

Bleen.

What happens if you put another box in the DMZ and configure it for connection happiness.

Valid question Faefae. Trying that now.

P.S. If Faefae outsmarts us all.....

Now THIS is interesting.

When I try to visit port 80 on the WAN IP to the local webserver on this machine, all port 80 traffic is temporarily blocked. Including my traffic to/from MT.net - yes, I'm getting MT.net timeouts when I try to access the server on this machine via the WAN IP, and not the LAN IP. If there's no port 80 traffic bound to this machine's webserver, I get perfect MT.net access. If there is port 80 traffic bound, I even have sites like google and microsoft timing out - but if there is none, everything works perfectly.

Hmmmmmm.

(Edit) And interestinger it gets. Inbound port 80 traffic blocks port 80 traffic completely to all my machines - send or receive.

Yep, it's the ISP.

Inbound traffic of a certain type (Email, SSH, web server, etc.) gets a block put on that port and no data is sent or received untill the block times out. Doesn't even matter if it originates from my internal network or if it's external, it still blocks it. This behavior has also been verified on a friend's network that subscribes to the same ISP. So, unless both of our routers (His is a real, genuine Cisco, mine is a d-link) have the exact same bug, it's the ISP doing it.

Bad ISP is bad.

I don't get it. How does your ISP know about internal traffic (192.168 -> router -> 192.168) when the traffic never leaves the router? Hitting a PFed port on the public IP of the router from the inside, your packages should go no further than the router itself, and then back to the internal network. Something is wrong here.

I don't know.

The same setup worked fine at my new apartment the last time I was there, Rev - same computer even.

I wish I had an answer for you, but simply by changing the ISP, it works now.

And ran into one final headache. I have everything working perfectly now, except for one hiccup. I cannot get a wireless AP to handle traffic properly. If I connect it to the network, the clients can get the DHCP address properly, and can run everything perfectly in-network, but external network it refuses to forward traffic from the Linux router.

It's as if I did not use the iptable command iptables -t nat -o eth0 -A POSTROUTING -j MASQUERADE in fact. Everything works perfectly except for passing traffic through eth0. eth1 and eth2 interact perfectly. I'm stumped, my switch works perfectly. But even if I set my wireless AP to full AP operation (Basically, wireless switch mode), it still won't pass wireless traffic through to eth0 - regardless of if it is connected to my switch on eth1 or eth2.

Any ideas guys? I'm having trouble figuring this out.

(Edit) Now this is very, very odd. I'm seeing a 500ms or so ping to even Google. Something's not right here.
(Edit2) Fuck the previous edit. Steam decided to download a shit ton of stuff without telling me. Non-relevance is not relevant.

Can you ping your router's external IP from a machine connected to the AP? Can you ping the router's remote peer? Does the AP has its own DHCP server? If so, does it assign IPs on the same subnet and does it assign a proper gateway?

There is no router now, Reverant. Just a Linux PC acting as a router which I've connected gigabit switches to.

No - No - Yes and no, I can set it to either and have - Yes if I set it to assign IPs to the correct subnet, but I can set it for pure dumb switch operation too.

(Edit) Samba, SSH, all work perfectly to the internal network if using either ethernet interface on a wired switch. I can't connect to the same from the external IP via wireless, although I am daisy-chaining switches in this case (wired switch->wireless AP/switch). I can do it fine from wired, however.

Well if the AP distributes IPs for a different subnet, and the AP is configured for dumb switch mode, its oviously not going to route to non-local IPs since there is no notion of a gateway in this setup?

Set it up to serve IPs on the same subnet as the wired net, and make sure the wireless clients get the proper gateway address.

If I set it to "smart" operation (assigning IPs), it is set to assign to the same subnet Rev. If I set it to dumb operation, it simply acts as a switch and passes IP assignment on to the Linux box.

Either method results in a big helping heap of fail in trying to get the wireless to pass traffic past the Linux box onto the internet.