UDP ports using PAT (NAT overload) - Help!

Discussion in 'Cisco' started by Greg Grimes, Oct 5, 2004.

  1. Greg Grimes

    Greg Grimes Guest

    Hi Everybody,

    Below is a thread that I started a while ago and didn't complete. If
    anyone has an answer I'd be very grateful.

    Greg

    -------
    -------

    > >> Hi Everyone,
    > >>
    > >> I have a Cisco 1720 router with 2 Ethernet and a T1 interface. One of
    > >> the ethernet interfaces is setup to use NAT. The problem is that my
    > >> company is writing a small application that uses UDP. The app uses a
    > >> single, specific source port address and calls a specific, static port
    > >> number at one remote address. The problem is that the external
    > >> interface of the router opens the exact same port number on the
    > >> external interface for each connection rather than opening a random
    > >> one. This causes the obvious problems with socket identification at the
    > >> other end and scuttles communication.
    > >>
    > >> Does anyone have an idea of how I could get the router to function the
    > >> way that I believe it is supposed to by default?
    > >>

    > > One mistake below. The client app uses a random port number, but
    > > multiple clients will often end up using the same source port number.
    > > This is when we run into problems.
    > >
    > >

    > Shouldn't matter. If two or more clients use the same source port, the
    > PAT router will use the same port # for the first, if it can, and then
    > different ones for the rest.
    >
    > So if three clients, A, B and C choose port 2137 as their source, then
    > after PAT the server might see them as D:2137, D:2138 and D:2139 and there
    > is no confusion, unless your app also uses the port # somewhere else in
    > the payload. The NAT router won't change that and the server might see
    > the three clients as the same.
    >
    > Perhaps if you provide a sanitised config and a show ip nat trans that
    > illustrates the problem, it will become clearer.


    Hi Martin,

    Sorry for the delayed response. Here's my sanitized config. The
    problem is that the PAT does not function the way you describe above,
    allocating a different external source port number for each subsequent
    socket with the same number.

    version 12.2
    service timestamps debug uptime
    service timestamps log uptime
    service password-encryption
    !
    hostname PTM
    !
    logging queue-limit 100
    enable secret 5 <removed>
    !
    memory-size iomem 25
    ip subnet-zero
    !
    !
    no ip domain lookup
    !
    no ip bootp server
    !
    !
    !
    !
    !
    !
    !
    interface Ethernet0
    ip address 172.XX.XX.XX 255.255.255.240
    full-duplex
    !
    interface FastEthernet0
    description connected to EthernetLAN
    ip address 192.168.1.1 255.255.255.0
    ip nat inside
    speed auto
    full-duplex
    !
    interface Serial0
    description connected to Internet
    ip address 61.XX.XX.XX 255.255.255.252
    ip access-group 101 in
    ip nat outside
    service-module t1 timeslots 1-24
    service-module t1 remote-alarm-enable
    !
    ip nat inside source list 1 interface Serial0 overload
    ip classless
    ip route 0.0.0.0 0.0.0.0 Serial0
    ip http server
    no ip http secure-server
    !
    !
    !
    access-list 1 permit 192.168.1.0 0.0.0.255
    access-list 1 deny any
    access-list 101 permit tcp any any established
    access-list 101 permit udp any host 192.168.1.5 eq ntp
    access-list 101 permit tcp any host 62.XX.XX.XX eq ftp
    access-list 101 permit tcp any host 62.XX.XX.XX eq ftp-data
    access-list 101 deny udp any any range 0 1030
    access-list 101 deny tcp any any range 0 1030
    access-list 101 deny tcp any any range 6000 6100
    access-list 101 deny udp any any range 6000 6100
    access-list 101 deny tcp any any range 5000 5003
    access-list 101 deny tcp any any eq 1080
    access-list 101 deny tcp any any eq 8080
    access-list 101 deny icmp any any echo
    access-list 101 deny tcp any any eq 1720
    access-list 101 permit ip any any

    !
    !
    line con 0
    exec-timeout 0 0
    password 7 <removed>
    login
    line aux 0
    password 7 <removed>
    login
    line vty 0 4
    access-class 1 in
    password 7 <removed>
    login
    !
    no scheduler allocate
    end


    Thanks,

    Greg
     
    Greg Grimes, Oct 5, 2004
    #1
    1. Advertising

  2. Greg Grimes

    PES Guest

    If the client app is set to use a specific port and the server app expects
    the packet to be destined to the port of the server to facilitate the ease
    of identifying what daemon should handle the packet, all should work. If
    the server app EXPECTS the packet not only to be destined to a specific port
    but sourced from a specific port, there would have to be intelligence about
    the application in the pat on the router. Otherwise, only one session is
    possible. This intelligence is a fixup on a pix and just built in
    functionality on a router (for example, but maybe a bad one, the ability to
    handle gre). Unless this is a well know application, you are going to be
    out of luck. Pat identifies flows based on src/dst address and port pairs.
    This is not a Cisco limitation, you would have this issue with any pat
    device.


    "Greg Grimes" <> wrote in message
    news:...
    > Hi Everybody,
    >
    > Below is a thread that I started a while ago and didn't complete. If
    > anyone has an answer I'd be very grateful.
    >
    > Greg
    >
    > -------
    > -------
    >
    >> >> Hi Everyone,
    >> >>
    >> >> I have a Cisco 1720 router with 2 Ethernet and a T1 interface. One of
    >> >> the ethernet interfaces is setup to use NAT. The problem is that my
    >> >> company is writing a small application that uses UDP. The app uses a
    >> >> single, specific source port address and calls a specific, static port
    >> >> number at one remote address. The problem is that the external
    >> >> interface of the router opens the exact same port number on the
    >> >> external interface for each connection rather than opening a random
    >> >> one. This causes the obvious problems with socket identification at
    >> >> the
    >> >> other end and scuttles communication.
    >> >>
    >> >> Does anyone have an idea of how I could get the router to function the
    >> >> way that I believe it is supposed to by default?
    >> >>
    >> > One mistake below. The client app uses a random port number, but
    >> > multiple clients will often end up using the same source port number.
    >> > This is when we run into problems.
    >> >
    >> >

    >> Shouldn't matter. If two or more clients use the same source port, the
    >> PAT router will use the same port # for the first, if it can, and then
    >> different ones for the rest.
    >>
    >> So if three clients, A, B and C choose port 2137 as their source, then
    >> after PAT the server might see them as D:2137, D:2138 and D:2139 and
    >> there
    >> is no confusion, unless your app also uses the port # somewhere else in
    >> the payload. The NAT router won't change that and the server might see
    >> the three clients as the same.
    >>
    >> Perhaps if you provide a sanitised config and a show ip nat trans that
    >> illustrates the problem, it will become clearer.

    >
    > Hi Martin,
    >
    > Sorry for the delayed response. Here's my sanitized config. The
    > problem is that the PAT does not function the way you describe above,
    > allocating a different external source port number for each subsequent
    > socket with the same number.
    >
    > version 12.2
    > service timestamps debug uptime
    > service timestamps log uptime
    > service password-encryption
    > !
    > hostname PTM
    > !
    > logging queue-limit 100
    > enable secret 5 <removed>
    > !
    > memory-size iomem 25
    > ip subnet-zero
    > !
    > !
    > no ip domain lookup
    > !
    > no ip bootp server
    > !
    > !
    > !
    > !
    > !
    > !
    > !
    > interface Ethernet0
    > ip address 172.XX.XX.XX 255.255.255.240
    > full-duplex
    > !
    > interface FastEthernet0
    > description connected to EthernetLAN
    > ip address 192.168.1.1 255.255.255.0
    > ip nat inside
    > speed auto
    > full-duplex
    > !
    > interface Serial0
    > description connected to Internet
    > ip address 61.XX.XX.XX 255.255.255.252
    > ip access-group 101 in
    > ip nat outside
    > service-module t1 timeslots 1-24
    > service-module t1 remote-alarm-enable
    > !
    > ip nat inside source list 1 interface Serial0 overload
    > ip classless
    > ip route 0.0.0.0 0.0.0.0 Serial0
    > ip http server
    > no ip http secure-server
    > !
    > !
    > !
    > access-list 1 permit 192.168.1.0 0.0.0.255
    > access-list 1 deny any
    > access-list 101 permit tcp any any established
    > access-list 101 permit udp any host 192.168.1.5 eq ntp
    > access-list 101 permit tcp any host 62.XX.XX.XX eq ftp
    > access-list 101 permit tcp any host 62.XX.XX.XX eq ftp-data
    > access-list 101 deny udp any any range 0 1030
    > access-list 101 deny tcp any any range 0 1030
    > access-list 101 deny tcp any any range 6000 6100
    > access-list 101 deny udp any any range 6000 6100
    > access-list 101 deny tcp any any range 5000 5003
    > access-list 101 deny tcp any any eq 1080
    > access-list 101 deny tcp any any eq 8080
    > access-list 101 deny icmp any any echo
    > access-list 101 deny tcp any any eq 1720
    > access-list 101 permit ip any any
    >
    > !
    > !
    > line con 0
    > exec-timeout 0 0
    > password 7 <removed>
    > login
    > line aux 0
    > password 7 <removed>
    > login
    > line vty 0 4
    > access-class 1 in
    > password 7 <removed>
    > login
    > !
    > no scheduler allocate
    > end
    >
    >
    > Thanks,
    >
    > Greg
     
    PES, Oct 6, 2004
    #2
    1. Advertising

  3. Greg Grimes

    Greg Grimes Guest

    The server app does not expect the packet to come from a particular
    remote port. It accepts any incoming UDP packets directed to a
    pre-determined local port number on the server. The server listen
    socket then spawns a child socket that sends/receives all subsequent
    UDP packets for that particular connection and communicates the
    port-change to the client at the application layer. The problem is at
    the client end. If we have three clients on our NAT all trying to
    connect to the server (outside the NAT), and they happen to all use
    the same client port number (happens pretty often), the NAT device
    (again a Cisco 1720) allocates a socket with the same client port
    number on the external interface and drops the packets from the other
    clients using that port number. What it *should* do is allocate an
    external socket for each client, give the first client the original
    port number, and simply increment the source port number for the rest
    of the sockets that contain the same source and destination port
    numbers.

    Personally, I think this is a bug in my IOS version (12.2T5), but I
    haven't found enough to prove that yet except for the fact that my $50
    broadband firewall at home (as well as a couple of wireless devices
    here) functions correctly with our app.


    "PES" <NO*SPAMpestewartREMOVE**SUCKS> wrote in message news:<41633f0d$>...
    > If the client app is set to use a specific port and the server app expects
    > the packet to be destined to the port of the server to facilitate the ease
    > of identifying what daemon should handle the packet, all should work. If
    > the server app EXPECTS the packet not only to be destined to a specific port
    > but sourced from a specific port, there would have to be intelligence about
    > the application in the pat on the router. Otherwise, only one session is
    > possible. This intelligence is a fixup on a pix and just built in
    > functionality on a router (for example, but maybe a bad one, the ability to
    > handle gre). Unless this is a well know application, you are going to be
    > out of luck. Pat identifies flows based on src/dst address and port pairs.
    > This is not a Cisco limitation, you would have this issue with any pat
    > device.
    >
    >
    > "Greg Grimes" <> wrote in message
    > news:...
    > > Hi Everybody,
    > >
    > > Below is a thread that I started a while ago and didn't complete. If
    > > anyone has an answer I'd be very grateful.
    > >
    > > Greg
    > >
    > > -------
    > > -------
    > >
    > >> >> Hi Everyone,
    > >> >>
    > >> >> I have a Cisco 1720 router with 2 Ethernet and a T1 interface. One of
    > >> >> the ethernet interfaces is setup to use NAT. The problem is that my
    > >> >> company is writing a small application that uses UDP. The app uses a
    > >> >> single, specific source port address and calls a specific, static port
    > >> >> number at one remote address. The problem is that the external
    > >> >> interface of the router opens the exact same port number on the
    > >> >> external interface for each connection rather than opening a random
    > >> >> one. This causes the obvious problems with socket identification at
    > >> >> the
    > >> >> other end and scuttles communication.
    > >> >>
    > >> >> Does anyone have an idea of how I could get the router to function the
    > >> >> way that I believe it is supposed to by default?
    > >> >>
    > >> > One mistake below. The client app uses a random port number, but
    > >> > multiple clients will often end up using the same source port number.
    > >> > This is when we run into problems.
    > >> >
    > >> >
    > >> Shouldn't matter. If two or more clients use the same source port, the
    > >> PAT router will use the same port # for the first, if it can, and then
    > >> different ones for the rest.
    > >>
    > >> So if three clients, A, B and C choose port 2137 as their source, then
    > >> after PAT the server might see them as D:2137, D:2138 and D:2139 and
    > >> there
    > >> is no confusion, unless your app also uses the port # somewhere else in
    > >> the payload. The NAT router won't change that and the server might see
    > >> the three clients as the same.
    > >>
    > >> Perhaps if you provide a sanitised config and a show ip nat trans that
    > >> illustrates the problem, it will become clearer.

    > >
    > > Hi Martin,
    > >
    > > Sorry for the delayed response. Here's my sanitized config. The
    > > problem is that the PAT does not function the way you describe above,
    > > allocating a different external source port number for each subsequent
    > > socket with the same number.
    > >
    > > version 12.2
    > > service timestamps debug uptime
    > > service timestamps log uptime
    > > service password-encryption
    > > !
    > > hostname PTM
    > > !
    > > logging queue-limit 100
    > > enable secret 5 <removed>
    > > !
    > > memory-size iomem 25
    > > ip subnet-zero
    > > !
    > > !
    > > no ip domain lookup
    > > !
    > > no ip bootp server
    > > !
    > > !
    > > !
    > > !
    > > !
    > > !
    > > !
    > > interface Ethernet0
    > > ip address 172.XX.XX.XX 255.255.255.240
    > > full-duplex
    > > !
    > > interface FastEthernet0
    > > description connected to EthernetLAN
    > > ip address 192.168.1.1 255.255.255.0
    > > ip nat inside
    > > speed auto
    > > full-duplex
    > > !
    > > interface Serial0
    > > description connected to Internet
    > > ip address 61.XX.XX.XX 255.255.255.252
    > > ip access-group 101 in
    > > ip nat outside
    > > service-module t1 timeslots 1-24
    > > service-module t1 remote-alarm-enable
    > > !
    > > ip nat inside source list 1 interface Serial0 overload
    > > ip classless
    > > ip route 0.0.0.0 0.0.0.0 Serial0
    > > ip http server
    > > no ip http secure-server
    > > !
    > > !
    > > !
    > > access-list 1 permit 192.168.1.0 0.0.0.255
    > > access-list 1 deny any
    > > access-list 101 permit tcp any any established
    > > access-list 101 permit udp any host 192.168.1.5 eq ntp
    > > access-list 101 permit tcp any host 62.XX.XX.XX eq ftp
    > > access-list 101 permit tcp any host 62.XX.XX.XX eq ftp-data
    > > access-list 101 deny udp any any range 0 1030
    > > access-list 101 deny tcp any any range 0 1030
    > > access-list 101 deny tcp any any range 6000 6100
    > > access-list 101 deny udp any any range 6000 6100
    > > access-list 101 deny tcp any any range 5000 5003
    > > access-list 101 deny tcp any any eq 1080
    > > access-list 101 deny tcp any any eq 8080
    > > access-list 101 deny icmp any any echo
    > > access-list 101 deny tcp any any eq 1720
    > > access-list 101 permit ip any any
    > >
    > > !
    > > !
    > > line con 0
    > > exec-timeout 0 0
    > > password 7 <removed>
    > > login
    > > line aux 0
    > > password 7 <removed>
    > > login
    > > line vty 0 4
    > > access-class 1 in
    > > password 7 <removed>
    > > login
    > > !
    > > no scheduler allocate
    > > end
    > >
    > >
    > > Thanks,
    > >
    > > Greg
     
    Greg Grimes, Oct 6, 2004
    #3
  4. Greg Grimes

    Rod Dorman Guest

    In article <>,
    Greg Grimes <> wrote:
    >The server app does not expect the packet to come from a particular
    >remote port. It accepts any incoming UDP packets directed to a
    >pre-determined local port number on the server. The server listen
    >socket then spawns a child socket that sends/receives all subsequent
    >UDP packets for that particular connection and communicates the
    >port-change to the client at the application layer.


    Its not clear to me what this means. Is this 'port-change' a "send all
    future packets to port nnn" or does it mean "I'm gonna send all my
    responses to your port nnn"?

    --
    -- Rod --
    rodd(at)polylogics(dot)com
     
    Rod Dorman, Oct 6, 2004
    #4
  5. Greg Grimes

    PES Guest

    "Greg Grimes" <> wrote in message
    news:...
    > The server app does not expect the packet to come from a particular
    > remote port. It accepts any incoming UDP packets directed to a
    > pre-determined local port number on the server. The server listen
    > socket then spawns a child socket that sends/receives all subsequent
    > UDP packets for that particular connection and communicates the
    > port-change to the client at the application layer. The problem is at
    > the client end. If we have three clients on our NAT all trying to
    > connect to the server (outside the NAT), and they happen to all use
    > the same client port number (happens pretty often), the NAT device
    > (again a Cisco 1720) allocates a socket with the same client port
    > number on the external interface and drops the packets from the other
    > clients using that port number. What it *should* do is allocate an
    > external socket for each client, give the first client the original
    > port number, and simply increment the source port number for the rest
    > of the sockets that contain the same source and destination port
    > numbers.
    >


    I agree with you. It should not allow a translation in the table with the
    external ip address and the source port the same when in fact there are
    connections to two or more pc's. I don't know if it would increment it by
    one. On a Pix it would randomize the source port unless you used norandseq.
    However, it would likely not be at least as random as it would on the pix.
    In any case, I think it should be unique. As long as the application isn't
    embedding its client port information, it should work with nat in this case.

    > Personally, I think this is a bug in my IOS version (12.2T5), but I
    > haven't found enough to prove that yet except for the fact that my $50
    > broadband firewall at home (as well as a couple of wireless devices
    > here) functions correctly with our app.



    It is quite possible a bug, given the information above. If you have
    smartnet, I would call cisco, try another IOS or both.

    >
    >
    > "PES" <NO*SPAMpestewartREMOVE**SUCKS> wrote in
    > message news:<41633f0d$>...
    >> If the client app is set to use a specific port and the server app
    >> expects
    >> the packet to be destined to the port of the server to facilitate the
    >> ease
    >> of identifying what daemon should handle the packet, all should work. If
    >> the server app EXPECTS the packet not only to be destined to a specific
    >> port
    >> but sourced from a specific port, there would have to be intelligence
    >> about
    >> the application in the pat on the router. Otherwise, only one session is
    >> possible. This intelligence is a fixup on a pix and just built in
    >> functionality on a router (for example, but maybe a bad one, the ability
    >> to
    >> handle gre). Unless this is a well know application, you are going to be
    >> out of luck. Pat identifies flows based on src/dst address and port
    >> pairs.
    >> This is not a Cisco limitation, you would have this issue with any pat
    >> device.
    >>
    >>
    >> "Greg Grimes" <> wrote in message
    >> news:...
    >> > Hi Everybody,
    >> >
    >> > Below is a thread that I started a while ago and didn't complete. If
    >> > anyone has an answer I'd be very grateful.
    >> >
    >> > Greg
    >> >
    >> > -------
    >> > -------
    >> >
    >> >> >> Hi Everyone,
    >> >> >>
    >> >> >> I have a Cisco 1720 router with 2 Ethernet and a T1 interface. One
    >> >> >> of
    >> >> >> the ethernet interfaces is setup to use NAT. The problem is that my
    >> >> >> company is writing a small application that uses UDP. The app uses
    >> >> >> a
    >> >> >> single, specific source port address and calls a specific, static
    >> >> >> port
    >> >> >> number at one remote address. The problem is that the external
    >> >> >> interface of the router opens the exact same port number on the
    >> >> >> external interface for each connection rather than opening a random
    >> >> >> one. This causes the obvious problems with socket identification at
    >> >> >> the
    >> >> >> other end and scuttles communication.
    >> >> >>
    >> >> >> Does anyone have an idea of how I could get the router to function
    >> >> >> the
    >> >> >> way that I believe it is supposed to by default?
    >> >> >>
    >> >> > One mistake below. The client app uses a random port number, but
    >> >> > multiple clients will often end up using the same source port
    >> >> > number.
    >> >> > This is when we run into problems.
    >> >> >
    >> >> >
    >> >> Shouldn't matter. If two or more clients use the same source port,
    >> >> the
    >> >> PAT router will use the same port # for the first, if it can, and then
    >> >> different ones for the rest.
    >> >>
    >> >> So if three clients, A, B and C choose port 2137 as their source,
    >> >> then
    >> >> after PAT the server might see them as D:2137, D:2138 and D:2139 and
    >> >> there
    >> >> is no confusion, unless your app also uses the port # somewhere else
    >> >> in
    >> >> the payload. The NAT router won't change that and the server might
    >> >> see
    >> >> the three clients as the same.
    >> >>
    >> >> Perhaps if you provide a sanitised config and a show ip nat trans
    >> >> that
    >> >> illustrates the problem, it will become clearer.
    >> >
    >> > Hi Martin,
    >> >
    >> > Sorry for the delayed response. Here's my sanitized config. The
    >> > problem is that the PAT does not function the way you describe above,
    >> > allocating a different external source port number for each subsequent
    >> > socket with the same number.
    >> >
    >> > version 12.2
    >> > service timestamps debug uptime
    >> > service timestamps log uptime
    >> > service password-encryption
    >> > !
    >> > hostname PTM
    >> > !
    >> > logging queue-limit 100
    >> > enable secret 5 <removed>
    >> > !
    >> > memory-size iomem 25
    >> > ip subnet-zero
    >> > !
    >> > !
    >> > no ip domain lookup
    >> > !
    >> > no ip bootp server
    >> > !
    >> > !
    >> > !
    >> > !
    >> > !
    >> > !
    >> > !
    >> > interface Ethernet0
    >> > ip address 172.XX.XX.XX 255.255.255.240
    >> > full-duplex
    >> > !
    >> > interface FastEthernet0
    >> > description connected to EthernetLAN
    >> > ip address 192.168.1.1 255.255.255.0
    >> > ip nat inside
    >> > speed auto
    >> > full-duplex
    >> > !
    >> > interface Serial0
    >> > description connected to Internet
    >> > ip address 61.XX.XX.XX 255.255.255.252
    >> > ip access-group 101 in
    >> > ip nat outside
    >> > service-module t1 timeslots 1-24
    >> > service-module t1 remote-alarm-enable
    >> > !
    >> > ip nat inside source list 1 interface Serial0 overload
    >> > ip classless
    >> > ip route 0.0.0.0 0.0.0.0 Serial0
    >> > ip http server
    >> > no ip http secure-server
    >> > !
    >> > !
    >> > !
    >> > access-list 1 permit 192.168.1.0 0.0.0.255
    >> > access-list 1 deny any
    >> > access-list 101 permit tcp any any established
    >> > access-list 101 permit udp any host 192.168.1.5 eq ntp
    >> > access-list 101 permit tcp any host 62.XX.XX.XX eq ftp
    >> > access-list 101 permit tcp any host 62.XX.XX.XX eq ftp-data
    >> > access-list 101 deny udp any any range 0 1030
    >> > access-list 101 deny tcp any any range 0 1030
    >> > access-list 101 deny tcp any any range 6000 6100
    >> > access-list 101 deny udp any any range 6000 6100
    >> > access-list 101 deny tcp any any range 5000 5003
    >> > access-list 101 deny tcp any any eq 1080
    >> > access-list 101 deny tcp any any eq 8080
    >> > access-list 101 deny icmp any any echo
    >> > access-list 101 deny tcp any any eq 1720
    >> > access-list 101 permit ip any any
    >> >
    >> > !
    >> > !
    >> > line con 0
    >> > exec-timeout 0 0
    >> > password 7 <removed>
    >> > login
    >> > line aux 0
    >> > password 7 <removed>
    >> > login
    >> > line vty 0 4
    >> > access-class 1 in
    >> > password 7 <removed>
    >> > login
    >> > !
    >> > no scheduler allocate
    >> > end
    >> >
    >> >
    >> > Thanks,
    >> >
    >> > Greg
     
    PES, Oct 7, 2004
    #5
  6. In article <4164801f$>,
    PES <NO*SPAMpestewartREMOVE**SUCKS> wrote:
    :I agree with you. It should not allow a translation in the table with the
    :external ip address and the source port the same when in fact there are
    :connections to two or more pc's. I don't know if it would increment it by
    :eek:ne. On a Pix it would randomize the source port unless you used norandseq.

    No, norandseq "Disables TCP Initial Sequence Number (ISN) randomization
    protection". Nothing to do with port numbers.
    --
    Aleph sub {Aleph sub null} little, Aleph sub {Aleph sub one} little,
    Aleph sub {Aleph sub two} little infinities...
     
    Walter Roberson, Oct 7, 2004
    #6
  7. Greg Grimes

    PES Guest

    "Walter Roberson" <-cnrc.gc.ca> wrote in message
    news:ck1vvf$hi4$...
    > In article <4164801f$>,
    > PES <NO*SPAMpestewartREMOVE**SUCKS> wrote:
    > :I agree with you. It should not allow a translation in the table with
    > the
    > :external ip address and the source port the same when in fact there are
    > :connections to two or more pc's. I don't know if it would increment it
    > by
    > :eek:ne. On a Pix it would randomize the source port unless you used
    > norandseq.
    >
    > No, norandseq "Disables TCP Initial Sequence Number (ISN) randomization
    > protection". Nothing to do with port numbers.
    > --
    > Aleph sub {Aleph sub null} little, Aleph sub {Aleph sub one} little,
    > Aleph sub {Aleph sub two} little infinities...


    You're absolutely right. I didn't have enough coffee.
     
    PES, Oct 7, 2004
    #7
  8. Greg Grimes

    Greg Grimes Guest

    (Rod Dorman) wrote in message news:<ck1ck1$qvd$>...
    > In article <>,
    > Greg Grimes <> wrote:
    > >The server app does not expect the packet to come from a particular
    > >remote port. It accepts any incoming UDP packets directed to a
    > >pre-determined local port number on the server. The server listen
    > >socket then spawns a child socket that sends/receives all subsequent
    > >UDP packets for that particular connection and communicates the
    > >port-change to the client at the application layer.

    >
    > Its not clear to me what this means. Is this 'port-change' a "send all
    > future packets to port nnn" or does it mean "I'm gonna send all my
    > responses to your port nnn"?


    It's the former. The client calls a particular port number to start
    communication. The listen socket spawns a socket on an alternate port
    and tells the client app to send all future UDP packets to that
    alternate port number.

    I don't have a Cisco support package anymore. If they know of the
    issue and have an IOS update that will solve the problem, will they
    generally give it to me?
     
    Greg Grimes, Oct 7, 2004
    #8
  9. Greg Grimes

    Rod Dorman Guest

    In article <>,
    Greg Grimes <> wrote:
    > ...
    >I don't have a Cisco support package anymore. If they know of the
    >issue and have an IOS update that will solve the problem, will they
    >generally give it to me?


    I'm not authorative on what Cisco would or wouldn't do but from what
    I've observed the only time they 'give' an IOS update is when its
    security related.

    --
    -- Rod --
    rodd(at)polylogics(dot)com
     
    Rod Dorman, Oct 8, 2004
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Greg Grimes
    Replies:
    3
    Views:
    4,203
    Greg Grimes
    Aug 16, 2004
  2. Ronald de Leeuw
    Replies:
    2
    Views:
    14,395
  3. Replies:
    1
    Views:
    792
  4. skweetis
    Replies:
    0
    Views:
    1,229
    skweetis
    Dec 11, 2006
  5. jayteezer
    Replies:
    1
    Views:
    1,439
    bod43
    May 23, 2010
Loading...

Share This Page