Re: Oddball Routing Issue
- From: secpgmr <secpgmr@xxxxxxxxx>
- Date: Tue, 1 Jan 2008 10:15:32 -0800 (PST)
On Jan 1, 9:06 am, "Thrill5" <nos...@xxxxxxxxxxxxx> wrote:
If you have Cisco routers, you have the hardware to do ACL's, NAT and
firewall.
"secpgmr" <secp...@xxxxxxxxx> wrote in message
news:36fac0eb-9591-4737-9301-09b55000930d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Good info. Thanks. I'll set up the sniffer to capture ICMP messages
from all sources for the server and also for the controller when I get
that sniffer set up.
In order to have an ACL, firewall or NAT issue, the network would have
to have hardware on it that I'm told it doesn't have.
I was hoping it was a common, simple issue, but doesn't appear to be
that at this point.
Since the telnet session connects but the controller session doesn't
UNTIL the instant after the telnet session connects, is there any
parameter in the packet that might be set on one and cleared on the
other that might cause the routing hardware to treat them
differently? It's not size. Neither packet is over 100 bytes.
Again, there is no problem when the controller is on the local
network.
Mike
On Dec 27, 7:36 pm, "Thrill5" <nos...@xxxxxxxxxxxxx> wrote:
If you can ping the end-point to end-point you do not have a routing
problem, you have some other type of problem. Routers don't distinguish
between ping packets, TCP packets on port 21 or TCP packets on port 6000.
Now if you can ping, but can't establish a connection, you could have an
ACL, firewall or NAT issue.
If you have an ACL issue, the server will get back an "ICMP Destination
Unreachable" message. To capture this from the server side of the
connection, your capture filter must set to include ICMP messages with a
destination ip address of the server and ANY source address. The source
address of the ICMP message will be the ip address of router interface
that
drops the packet, not the address of the controller. Of course this is
true
ONLY if you do NOT have "no icmp destination unreachable" configured on
the
router that is dropping the packet.
"secpgmr" <secp...@xxxxxxxxx> wrote in message
news:2a4942cc-cbfb-4a3f-bce4-1190db3d1c3b@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I don't have access to the routers along the route, so can't debug at
that level. The sniffer is on the server.
There's no NAT involved. The IPs of the server and controller are in
different class C's of the same Class B within a 10 network.
I can't imagine what else would be doing port triggering. I'm told
the network is wide open internally.
My next step is to sniff at the controller to see what's actually
arriving, although that's going to require some coordination as
there's no one on the ground there at the moment.
Mike
Barry Margolin wrote:
In article
<1e5d3ff7-6946-46a8-9879-2cdcec77e...@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
secpgmr <secp...@xxxxxxxxx> wrote:
I have an oddball connection issue that appears to be related to the
routing equipment between the two end points.
What kid of routing equipment is it? All you've said is that there
are
no firewalls. Are any of them doing NAT? Something else with a
dynamic
port trigger?
I have a server trying to connect to an access control system
controller across the country over a WAN. When I sniff the
connection
between the server and the controller, I see a sequence of SYN
packets
to the controller service port (> 2000 < 4000) on the controller
with
no SYN ACK from
the controller.
However, if I open a telnet session to the controller on the port
where telnet is listening on the controller (> 8000), suddenly the
server gets
a SYN ACK on the controller service port and the controller comes
online.
Where are you sniffing, on the network with the server or the network
with the controller?
If I break the connection on the controller service port and try to
re-
establish it, I just get a sequence of SYN packets with no SYN ACK
until I open another telnet session again.
Seems the telnet session is establishing some kind of state that is
needed for the connection to occur that cannot be created on the
controller service port for some reason.
The controller connects perfectly on the local network. The problem
only occurs over the WAN. There are no firewalls between the two
end
points.
Can you use "show ip packet" on all the routers along the way, to see
where the packets are getting lost?
--
Barry Margolin, bar...@xxxxxxxxxxxx
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Sorry for the lack of precision in my response. You're right of
course, the necessary hardware is present. Meant to say that I'm told
there's no hardware configured to utilize that functionality between
here and there.
.
- References:
- Re: Oddball Routing Issue
- From: Thrill5
- Re: Oddball Routing Issue
- Prev by Date: Re: Oddball Routing Issue
- Next by Date: Re: Oddball Routing Issue
- Previous by thread: Re: Oddball Routing Issue
- Next by thread: Re: Oddball Routing Issue
- Index(es):
Relevant Pages
|
Loading
