Re: Trying to telnet and ping through a bsd gateway fails

[Nick <nagray@austin.rr.com>]

What a day.

         I mail earlier because I had a rule problem. I finally commented 
out the rules and rebooted. I would edit the rules and run pfctl -R 
/etc/pf.conf and test the connections again. I don't think this is what you 
would call a bug, but I think my boss was right about the problem with 
named services.

I turned on every rule and loaded them one at a time. After I failed to 
find a problem I convinced myself that I was loosing my mind. I rebooted 
and I can't telnet again. Now I now that reloading the rules works because 
I wasn't paying attention and shut ssh of and blew away my connection. I 
sill had the telnet connection up through esp and was able to restore my 
ssh rule and log back in.

I will start in the morning with all the rules off and reboot after every 
rull change until I find the problem.

Also can anyone tell me if telnet is doing reverse name lookups of the 
connecting host? I am thinking that the connection delay I am seeing is 
being caused by that. I will test that in the morning


At 04:18 PM 3/1/2002 -0600, you wrote:
>OK I have no idea of what I did but it works. I noticed that it seems to 
>take forever to get a connection up. but maybe lack of patience was the 
>problem all along. I would like to hear if anyone else is using telnet 
>through esp and notices that the connection takes awhile to come up.
>
>BTW I all found a misconfiguration: the daemon has a -k option (in the 
>inetd.conf) but the man page does not. Not sure which is correct, for my 
>test I put in "-a none -y"
>
>
>At 03:59 PM 3/1/2002 -0600, Nick wrote:
>>I can tell I am tire of this problem. After I sent the message I realized 
>>why without the original vpn structure in place I can't ping  (or 
>>anything else for that matter) from one private subnet to the other.
>>
>>So I looked at it again and put the vpn back in place. I am using a 
>>script to setup the vpn. This is similar to the one that is included (If 
>>my memory serves)
>>
>>
>>I am now using my windows box as a client on the inside of the .35 
>>network (192.168.35.4) and pinging the inside address of the gateway 
>>(192.168.30.2)
>>
>>192.168.35.4<-->192.168.35.51/24.27.15.30<--Internet-->24.242.137.194/192.168.30.2
>>
>>Pinging 192.168.30.2 with 32 bytes of data:
>>
>>Reply from 192.168.30.2: bytes=32 time=121ms TTL=254
>>Reply from 192.168.30.2: bytes=32 time=50ms TTL=254
>>Reply from 192.168.30.2: bytes=32 time=60ms TTL=254
>>Reply from 192.168.30.2: bytes=32 time=100ms TTL=254
>>
>>Ping statistics for 192.168.30.2:
>>     Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
>>Approximate round trip times in milli-seconds:
>>     Minimum = 50ms, Maximum =  121ms, Average =  82ms
>>
>>As you can see this works. This was done in a DOS box.
>>
>>trying a tracert from the same box does this
>>
>>C:\>tracert 192.168.30.2
>>
>>Tracing route to 192.168.30.2 over a maximum of 30 hops
>>
>>   1   <10 ms   <10 ms   <10 ms  192.168.35.51
>>   2   141 ms    20 ms    30 ms  192.168.30.2
>>
>>Trace complete.
>>
>>Looks good so far, now the problem.
>>
>>If I try to run telnet from the DOS box (192.168.35.4-->192.168.30.2) it 
>>goes into never (return) land.
>>I bring up telnet client and attempt to telnet to the secure side 
>>(192.168.35.4-->192.168.35.51) no return.
>>I bring up telnet client and attempt to telnet to the other secure side 
>>(192.168.35.4-->192.168.30.2) no return.
>>
>>My boss has a theory about it having something to do with named services. 
>>Strangely enough I swear it worked last week.
>>
>>Thanks 10^6 for any assistance.
>>
>>Nick
>>--
>>Vides Credendo!
>>Nick Gray
>>Senior Network Engineer
>>Bruzenak inc.
>>nagray@bruzenak.com
>
>--
>Vides Credendo!
>Nick Gray
>Senior Network Engineer
>Bruzenak inc.
>nagray@bruzenak.com

--
Vides Credendo!
Nick Gray
Senior Network Engineer
Bruzenak inc.
nagray@bruzenak.com