Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 2 subscribers
  • Views 3857 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SSH DNAT not working

awesomo
UTM 9.313-3
SG125W

I have a /29 block from my ISP and have SSH disabled on the UTM.

I am trying to forward port 22 from one of my statics to an internal device. I can SSH into the device internally with no issue. But from outside, I get a connection refused.

Here is the DNAT entry I made. It doesn't matter if I specify SSH or not for the destination translation. I have 6 other entries going to this same device and they all work. I just can't get SSH to work. Does anyone know what is going on here?



I even tried a different static and a different internal device with SSH enabled and it STILL didn't work.


This thread was automatically locked due to age.
  • 0
    1)  Just be be certain, for going to, you have the External (WAN) (Address) object and not network or broadcast?

    2)  There isn't anything upstream of the UTM, like a bridged ISP modem or router, that has SSH enabled?

    3)  Your ISP isn't filtering ports, is it?  This is common on residential lines.

    4)  No other DNATs with a lower # that might already be doing something with SSH, especially if you're using service groups?

    5)  If you use tcpdump from the shell, do you see the connection attempts?  If not, the packets are never reaching the UTM.

    6)  I assume that you are testing this from a client that is out on the internet and NOT trying to connect to the WAN address from within the LAN.

    7)  Did you modify the built-in SSH service definition?  Make certain that the source port is 1:65535 and the destination port is  TCP 22.

    8)  Have you tried port translation?  For the Matching Condition service, create and use something greater than 1024, then for the Action service, use SSH (TCP 22).
  • 0 in reply to Scott_Klassen
    1. Yes.
    2. No, nothing is upstream with SSH.
    3. Not blocking. This worked before on their old Juniper firewall
    4. No other DNATs before this entry have a destination/range including port 22.
    5. Yes. A little suspicious, starting to look like a setting on the device itself.
    6. Yes.
    7. No.
    8. For grins I did try to translate 4100 to 22 and had the same result.

    This is a linux server that I have next to no control over.

    At this point, I can only assume it is one of two things.
    1. The person that controls this server has a software firewall running that is restricting connections originating from certain subnets. (Although they swear it does not, but won't give me access to check, sigh...)
    2. A bug.

    Next time I am there, I will enable ssh on something else and try to setup a DNAT going to my new device, if it works, it's #1, if not, it's #2.
  • 0
    Enable loggin for the DNAT, try to connect from outside, then show a corresponding line from the full firewall log (not the live log).
  • 0 in reply to scorpionking
    Enable loggin for the DNAT, try to connect from outside, then show a corresponding line from the full firewall log (not the live log).


    2015:07:01-12:15:37 173 ulogd[11511]: id="2000" severity="info" sys="SecureNet" sub="packetfilter" name="Packet logged" action="log" fwrule="62012" initf="eth1" srcmac="00:22:2d:6a:b6:ce" dstmac="00:1a:8c:49:17:89" srcip="76.112.***.***" dstip="173.162.***.***" proto="6" length="52" tos="0x00" prec="0x20" ttl="122" srcport="49884" dstport="22" tcpflags="SYN"


    That is the only line that shows up.
  • 0
    Does "MBG" violate #3 in Rulz?  If not, then I vote for the restriction.  After all, does any of us have "Any" in 'Allowed networks' in 'Shell Access'?

    Cheers - Bob
  • 0 in reply to BAlfson
    Does "MBG" violate #3 in Rulz?  If not, then I vote for the restriction.  After all, does any of us have "Any" in 'Allowed networks' in 'Shell Access'?

    Cheers - Bob


    No, it does not violate #3, the interface for the MBG definition was set to 

    I'm 100% sure it is a restriction on the device itself. It is like pulling teeth with the person that manages this. He keeps pushing blame onto me and showing "proof" that it's my problem. I read the same logs he provides and it in fact says the exact opposite. There is a bit of Dunning Kruger going on with this guy.

    I'm just glad i've covered my bases and I hope to have it resolved soon even if I have to get management to get him to release the root credentials to me.