Hello.  I have a network setup as follows:

OpenBSD (3.1) server --> OpenBSD (3.5) bridging firewall --> Briteport
8120 ---768/1.5 SDSL line --> ( INTERNET )

Whenever I make an outbound connection from the OpenBSD server to two
telnet bbs's, if I leave my connection idle long enough it locks up. 
Upon lockup, I can go to the firewall and see that a connection is
established.  Likewise, on the server (using netstat -an on both) it
shows the connection is established, however the connection is
obviously dead.  Typing anything into either telnet session yields no
results.   I do notice however that if I type something (like holding
down the spacebar) the "Send-Q" of the server increases.  I'm guessing
that the tcp connection is timing out for some reason but I can't
figure out why.  When remotely sshing into the server, I can get
around this by specifying my ssh client software (putty) to send a
null packet every 10 seconds.  However there is no such option for
telnet.  Likewise, I don't want to have to send a null packet every 10
seconds...I simply want to specify the tcp timeout.  Even if there is
a telnet argument to pass to specify the timeout, I can't use this, as
I use programs that use telnet protocol to talk to a BBS system in
which this setting doesn't exist.  I need to change something with the
tcp/ip stack or router to fix this.

I have also done some research on OpenBSD sysctl and the sysctl variable
net.inet.tcp.keepintvl seems to relate to tcp keep alives.  I have
reduced this from 150 to 30 on both the firewall and the server to no
avail.

I hope someone knows the answer to this because it's driving me crazy!

---

Request for Question Clarification by maniac-ga on 04 Aug 2004 19:20 PDT

Hello Robstarusa,

The time out could be at one of several locations:
 - the firewall
 - the Briteport (not sure...)
 - the remote BBS machine

For example, a Linux system (sorry - not BSD) operating as a firewall
/ NAT can be configured using:
  http://www.thelinuxreview.com/howto/IP-MASQ/x1946.htm
I will certainly dig further to see if I can find the BSD equivalent.

I doubt you can apply a fix if its the remote machine or the Briteport
(unless you have some configuration to adjust).

Just curious, is there some reason you don't use PuTTY for your telnet
sessions and enable the keepalive like you do with your SSH sessions?

  --Maniac

---

Clarification of Question by robstarusa-ga on 04 Aug 2004 19:45 PDT

Hello.

I use putty + ssh + keep alive to make my ssh connections not time
out.  I don't think it's the remote machine because a similar firewall
on another machine (openbsd 3.4) which is now in pieces worked fine
and didn't have this timeout problem.  The main change was 1) making
the firewall rules stricter and 2) using openbsd 3.5 instead of 3.4. 
It's possible it's the briteport, but as far as I cna see there's
nothing to change there.  I don't know how it COULD be that since both
nat & firewalling are turned off on that.  My telnet sessions are made
from within my ssh sessions.  The reason for this is that my bbs
client is unix based, hence I ssh to my unix machine in order to use
the bbs client.  The bbs client uses unix protocol.  Likewise, I do
telnet connections from there because I use screen on the unix machine
once I'm sshed in and "screen -dr" to reconnect to my telnet sessions
as I switch locations (home/work/friends house/clients location/etc).

I hope this makes sense.  If not, I'll post another clarification.

---

Clarification of Question by robstarusa-ga on 04 Aug 2004 19:48 PDT

As an addendum:  While troubleshooting this, I ran "tcpdump -n -e -ttt
-i pflog0" to see all packets blocked by the firewall (my default rule
is "block in log all) on both the ingoing and outgoing interface.  I
left the session idle for 30 minutes (the timeout seems to occur in
less than 30 minutes) and when I came back, tcpdump didn't show
anything that was blocked.  I'm really not sure where to go from here
except physically removing the firewall to narrow it down and see if
it is the briteport or not (but I still can't see why....as far as I
know, a non-firewalling, non-natting router shouldn't affect inbetween
sessions except for routing packets).

---

Clarification of Question by robstarusa-ga on 04 Aug 2004 19:56 PDT

As an addendum:  While troubleshooting this, I ran "tcpdump -n -e -ttt
-i pflog0 src host <remote telnetserver ip> or dst host
<telnetserverip>" to see all packets blocked by the briding
firewalling going to or from the remote server (my default rule is
"block in log all) on both the ingoing and outgoing interface.  I left
the session idle for 30 minutes (the timeout seems to occur in less
than 30 minutes) and when I came back, tcpdump didn't show anything
that was blocked.  I'm really not sure where to go from here except
physically removing the firewall to narrow it down and see if it is
the briteport or not (but I still can't see why....as far as I know, a
non-firewalling, non-natting router shouldn't affect inbetween
sessions except for routing packets).

P.S.  Above "The bbs client uses unix protocol " Should be "The bbs
client uses telnet protocol".  Sorry about that.

---

Clarification of Question by robstarusa-ga on 05 Aug 2004 06:05 PDT

More troubleshooting:

I have removed the openbsd 3. server from the configuration.  I have
tried the telnet connection from the OpenBSD 3.5 bridging firewall
itself (it has an ip) with the same problem....one one set of
interfaces!

In reality the firewall has 4 interfaces:
fxp0/fxp1 (dsl line one)
vr0/vr1 (dsl line two)

These interafces are SEPARATE and cannot talk to each other.

bash-2.05b# ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33224
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7
vr0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        address: 00:40:63:d4:0d:c7
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet [REMOVED] netmask 0xfffffff8 broadcast [REMOVED] inet6
fe80::240:63ff:fed4:dc7%vr0 prefixlen 64 scopeid 0x1
vr1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        address: 00:40:63:d4:0d:c6
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet6 fe80::240:63ff:fed4:dc6%vr1 prefixlen 64 scopeid 0x2
fxp0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        address: 00:90:27:8c:b6:75
        media: Ethernet autoselect (10baseT)
        status: active
        inet [REMOVED] netmask 0xfffffff8 broadcast [REMOVED]
        inet6 fe80::290:27ff:fe8c:b675%fxp0 prefixlen 64 scopeid 0x3
fxp1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        address: 00:90:27:8c:b6:76
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet6 fe80::290:27ff:fe8c:b676%fxp1 prefixlen 64 scopeid 0x4

The bridges are configured as such:

bash-2.05b# brconfig bridge0
bridge0: flags=41<UP,RUNNING>
        Configuration:
                priority 32768 hellotime 2 fwddelay 15 maxage 20
        Interfaces:
                fxp1 flags=3<LEARNING,DISCOVER>
                        port 4 ifpriority 128 ifcost 55
                fxp0 flags=3<LEARNING,DISCOVER>
                        port 3 ifpriority 128 ifcost 55
        Addresses (max cache: 100, timeout: 240):
                00:26:54:0a:0b:52 fxp1 0 flags=0<>
                08:00:09:5a:65:ef fxp1 1 flags=0<>
                00:20:6f:15:08:11 fxp0 1 flags=0<>
                00:30:bd:09:ab:09 fxp1 0 flags=0<>

bash-2.05b# brconfig bridge1
bridge1: flags=41<UP,RUNNING>
        Configuration:
                priority 32768 hellotime 2 fwddelay 15 maxage 20
        Interfaces:
                vr1 flags=3<LEARNING,DISCOVER>
                        port 2 ifpriority 128 ifcost 55
                vr0 flags=3<LEARNING,DISCOVER>
                        port 1 ifpriority 128 ifcost 55
        Addresses (max cache: 100, timeout: 240):
                00:30:bd:09:ab:29 vr1 1 flags=0<>
                00:30:bd:08:ea:d4 vr1 0 flags=0<>
                00:e0:eb:74:90:0e vr0 1 flags=0<>
                00:10:dc:98:72:8f vr1 0 flags=0<>

These interfaces cannot directly talk to each other

The bridge itself has these IP addresses for remote administration,
security patches, etc.  Trying from the vr0/1 interfaces, I am seeing
the same problem.
With the fxp0/1 interfaces the problem doesn't seem to exist!

This means it's a problem on either with the bridge because of
software, hardware, or with the briteport which is upstream.  I
suppose the other possibilities are network cabling (I'd imagine I'd
see more intermittancy) or switch configuration.....(doubtful as the
fxp's work..)

Tonight I will swap the interfaces so the fxp (working) is connected
to the briteport and see if it still disconnects me.

Rob

---

Clarification of Question by robstarusa-ga on 06 Aug 2004 05:25 PDT

well, the fxp connected to the briteport shows the same symptoms :(  I
still don't have a solution....

The briteport _DOES_ do pppoe.  I'm wondering if it's something
related between pppoe and openbsd.  The 2nd dsl line that works fine
DOESNT use pppoe.

Hm

---

Clarification of Question by robstarusa-ga on 06 Aug 2004 06:51 PDT

Well, it's not pppoe and openbsd.  I have the same timeout issues with
a windows XP machine.

Rob

---

Clarification of Question by robstarusa-ga on 09 Aug 2004 07:42 PDT

Hello,

After I contacted my ISP, they said they'd "look into it".
About 4 hours later my disconnects stopped happening.

I would like to cloes out this question and I'd like to tip maniac-ga
for pointing me in the right direction.

Is this possible?

Thanks,

Rob

---

Request for Question Clarification by maniac-ga on 09 Aug 2004 19:13 PDT

Hello Robstarusa,

I am glad you have a solution and thank you for the kind words. If you
wish to pay me, please do not close the question.

Instead:
 - adjust the price to what you think is appropriate
 - make another "question clarification" so I get notified
Then I will put together a more complete answer and post it. At that
point, you will have the opportunity to rate the answer, request
answer clarifications, and so on.

  --Maniac

---

Clarification of Question by robstarusa-ga on 09 Aug 2004 21:54 PDT

Ok, here is the last clarification.

Rob

---

Clarification of Question by robstarusa-ga on 10 Aug 2004 08:02 PDT

Oh no......the whole problem has returned!

Supposedly the ISP is "working on it" so to say.

Rob