PIX syslog messages

In article , AM wrote: :I'm trying to connect from a PC behind my Firewall to a 837 router on the Internet :The router can accept only ssh connections and only from a particular subset of public IP addresses. It can not accept :telnet connections. When trying to connect via telnet I obtain "Connection refused" and it is correct. :But when trying to connect via ssh on the PIX syslog I see the following.

:Apr 6 11:59:08 fw-ts-itbs-area.italtbs.com %PIX-6-106015: Deny TCP (no connection) from /7 to /1119 flags SYN ACK on interface Tunn_Estero_Endpoint

Looking at that list of errors, what it suggests to me is that the IP address you are attempting to ssh to may not be the same as the IP address that is replying. If true, then the PIX is not going to recognize the packet as being a reply packet and will drop it with log messages such as you are seeing.

Notice you indicate -- if you are ssh'ing to the 837 from "inside" the 837 then you would expect it to be the -private- IP that replied.

If I recall correctly, there are ways in IOS to control which IP is used for some of the traffic from the device (837) itself; I do not recall the details at the moment.

replying. If true,

"inside" the 837

192.168.23.x [PIX] (PIX public IP) Internet cloud (837 public IP)[837]

the command given from 192.168.23.x is ssh -l (837 public IP)

Alex.

Anyway I will have a look about settings of ssh server It is strange 837 uses a very low port to initiate connections ... /7 ...

instead of those above 1023.

Alex.

That's tcp echo, it's usually used by global load balancers as one way to find the closest server to serve the connection, looking on the timestamp informations in the tcp header of your replies. Don't know why your 837 it's behaving like that, maybe you have turned on some strange feature on the router. Beside that, are your ssh connection attempts actually succeding or failing? Bye, Tosh.

Ciao Tosh,

the attempts fail each time. The client returns "Connection time out". SSH connections from LAN side are always successful. I don't know whether the problem is on ATM side configuration or on SSH server. I will wipe the config, change the IOS to any version and ten reload the current and write from the scratch and by hand the current configuration. But if you have another solution I will appreciate it.

A presto, Alex.

Funny, two Italian guys talking english to each other about an issue that probably the rest of the world doesn't care of. This is a good exemple of technology that doesn't always shorten roads. Anyway, back to your problem, I'm not aware of any ios feature that uses tcp echo, so I can only support your plan to refresh the config getting rid of all the exotic commands you may find into. A final thought, are you sure you are sshing to the right device? Maybe your ssh is intercepted by some nat or policy routing or balancer or whoknows device in between. Bye, Tosh.

In article , AM wrote: :Anyway I will have a look about settings of ssh server :It is strange 837 uses a very low port to initiate connections

:/7

But the 837 isn't initiating the connection -- the PIX is. The 837 is the one replying.

The port 7 and port 8 references in the logs suggest to me that the 837 is NAT'ing the reply back to you. The port 7 and 8 responses are not going to match the port 22 that the PIX is expecting the response on so the PIX isn't going to know it as the same connection.

The question then becomes "Why is the reply back NAT'd" ? That would have to depend on the setup of the 837 NAT, and on whether the 837 has the firewall feature set or is using reflexive ACLs. The 837 "should" know to exempt replies from NAT, but if it is not using FFS or reflexive ACLs then maybe it doesn't know that and is blindly using a rule that NAT's all outgoing traffic including traffic from the 837 public IP.

Very easy to do this by using "permit any" in your NAT ACL. Makes it impossible to telnet, or in this case ssh, into the NAT outside interface.

The reason this happens is that NAT is applied to traffic crossing the router from inside to outside, *and* to local traffic from the router.

So people configure their NAT to monkey with the addresses in whatever way it likes, and then act surprised when it does.

I agree with you that a "permit any" in the nat acl is bad practice, but I also remember you that in order to get natted the traffic has to traverse both a "nat inside" and a "nat outside" interface and local traffic should not do that, at least when you access the outside interface from the outside. To say all, I think that should (not must) be the case in which the op configured a static nat with the outside interface of the router as the "inside global", which is a completely different issue, although nat related. This way the ssh to the outside interface will be directed, say, to a windows machine that doesn't know how to handle it. Bye, Tosh.

Nope, local traffic from the router will be natted if it matches the NAT ACL. I've seen it happen many times.

I'm not following you, perhaps we are talking about two different issues, it'll be very helpful if you can do an example with some piece of config. Maybe it's time the op tells us if he solved and how, just in respect of who tried to help him. Bye, Max.

I'm not following you, perhaps we are talking about two different issues, it'll be very helpful if you can do an example with some piece of config. Maybe it's time the op tells us if he solved and how, just in respect of who tried to help him. Bye, Max.

I'm not following you, perhaps we are talking about two different issues, it'll be very helpful if you can do an example with some piece of config. Maybe it's time the op tells us if he solved and how, just in respect of who tried to help him. Bye, Tosh.

I'm not following you, perhaps we are talking about two different issues, it'll be very helpful if you can do an example with some piece of config. Maybe it's time the op tells us if he solved and how, just in respect of who tried to help him. Bye, Tosh.

! interface Ethernet0 ip address 192.168.25.254 255.255.255.0 ip nat inside ! interface Serial0/0 ip address 172.16.27.2 255.255.255.252 ip nat outside ! ip nat inside source list 1 interface Serial0/0 overload ip route 0.0.0.0

0.0.0.0 Serial0/0 ! access-list 1 permit any !

Try and telnet to 172.16.27.2; times out.

Remove "ip nat outside" from S0/0 or change access list 1 to "permit 192.168.25.0 0.0.0.255" and telnet to 172.16.27.2 will succeed.

In my knowledge this is not normal, thats not the same to say you are wrong, simply has to be a bug or something. With nat overload (or pat) ios maintains a table of all the dynamic translations created absolutely only when traffic flows from the inside to the outside and they have port numbers higher than 1024 appearing on the outside, I'd like to know what the hell an ssh from the outside has to do with that. Bye, Tosh.