Solved PF and Long Lived Connections?

jasonvp

jasonvp

Hey folks -

I'm at wit's end trying to troubleshoot this problem and I'm specifically not blaming pf. Rather I'm trying to eliminate it as a source of trouble. My network has a public and private VLAN with my FreeBSD router routing between the two. The third interface on the router is talking to my ISP. I have pf running on the router to allow/deny specific traffic inbound, all outbound, as well as NAT for the private VLAN. There's no other ISP box in the house doing L3 stuff; it's L2 out to their network.

All works fine. On the public VLAN, I have a Mac that is trying to send an HLS stream to YouTube. And it works, too, for exactly 60 minutes. At the 60 minute mark, the stream gets closed down. I watched a tcpdump on my Mac, and strangely the YouTube server is sending a [F.] but I never see a preceding [F] from the Mac.

My question is: will pf time out hour-long TCP sessions? Or am I looking in the wrong place?

Thanks.
 
I can't answer for your specific case, but I've had ssh sessions via pf and they can stay open for days.

I've had firewalls outside my control that have terminated long running FTP or ssh sessions and had to use keep alive mechanisms for those.

But sorry, can't give you a more useful answer - I don't think it would be pf. Is there any way you can test the set-up with pf completely disabled but everything else as close to the same as possible?
 
We're running VPN and VoIP sessions through (multiple) routers with PF and without any extra configuration they stay up for weeks. (BGP sessions running throuh those VPN connections are currently at 12w2d16h...)

Do you run VoIP over that connection? If those sessions are up for longer than 60min the problem most likely isn't PF related or even on your side.

Can you try sending that stream from a different machine (OS) to rule out any short-lived timer on the Mac side? I don't think there is any - I much rather think there's some kind of session limit on the youtube side, possibly you have to verify or upgrade your account to be able to stream for longer periods. But to verify this I'd try a completely different OS.
 
jasonvp said:
My question is: will pf time out hour-long TCP sessions? Or am I looking in the wrong place?
Click to expand...
Not in my experience.
I had to keep Firefox open with an interface connected to the Turing Test site for 24 hours solid or be disqualified.
It could have been up a month with no problem. It worked flawlessly.

I didn't even have to make port adjustments to my pf ruleset from what I've posted here because I initiated the connection.
 
PF doesn't time out states as long as there's traffic. The timeouts only happen if there hasn't been a packet passing the firewall. With SSH you could time-out the firewall states if the connection has been idle for a long time. For SSH you can prevent this from happening by enabling KeepAlive. This will send a noop packet periodically and that will prevent the firewall state from timing out.

With regards to the Youtube stream, as long as the stream is active (i.e. continuously sending packets) then the firewall state can't timeout and this shouldn't be an issue.
 
I appreciate everyone's replies. I, too, have had long ssh sessions open and that should have told me that pf is OK w/those.

VladiBG said:
In Pf.conf do you have Set timeout tcp.established?
Check what timeouts do you have via pfctl -st
Click to expand...

I'm not specifically setting the timeouts in the config file.

Code: 
# pfctl -st
tcp.first                   120s
tcp.opening                  30s
tcp.established           86400s
tcp.closing                 900s
tcp.finwait                  45s
tcp.closed                   90s
tcp.tsdiff                   30s
udp.first                    60s
udp.single                   30s
udp.multiple                 60s
icmp.first                   20s
icmp.error                   10s
other.first                  60s
other.single                 30s
other.multiple               60s
frag                         30s
interval                     10s
adaptive.start            60000 states
adaptive.end             120000 states
src.track                     0s

Those are all the defaults if I'm not mistaken.

sko said:
Can you try sending that stream from a different machine (OS) to rule out any short-lived timer on the Mac side? I don't think there is any - I much rather think there's some kind of session limit on the youtube side, possibly you have to verify or upgrade your account to be able to stream for longer periods. But to verify this I'd try a completely different OS.
Click to expand...
I'm working on this as I type; sending an HLS stream up via my Windows rig. As far as "longer streams", this doesn't happen with YouTube's RTMP streaming, just their HLS one.

diizzy said:
I would look at your streaming software and possibly how it's connected, what you could try is to setup a local streaming server on another box
Click to expand...
Definitely have done that before, but again: this is HLS not RTMP. But thanks for the idea.
 
I just ran through a two hour HLS stream from my Windows rig that's on the same network as my Mac. No issues. So pf isn't to blame. This has something to do with the Mac, OBS running on the Mac, or other software on the Mac, it appears.

Marking "Resolved". Thanks all.
 
jasonvp said:
My question is: will pf time out hour-long TCP sessions? Or am I looking in the wrong place?
Click to expand...
After letting a youtube video play while browsing with www/firefox-esr it stopped at the one hour mark with this message from youtube:
Video paused. Continue watching?
Click to expand...

I had an option to click "Yes" to continue listening to Living Colour in concert.
YES, YES, a thousand times YES!
Clicking "Yes" once continued the video.
 
You must log in or register to reply here.
Back
Top