# Can't ssh from outside. Can locally



## gruvin (Nov 10, 2011)

Hi

I have a FreeBSD acting as my Internet gateway.

I have two (Realtek) network interfaces, re0 (WAN) and re1 (LAN). I'm using IPF with NAT on FreeBSD 8.2.

I have moved sshd to a different port, 8xxx. I can ssh from within my local LAN (via re1) on this custom port without issue. But when I attempt to ssh from a remote local to my public IP (on re0) I get 
	
	



```
failed: Operation timed out
```

I suspect something in the firewall configutaion, but have no idea what. I'm new to IPF.

Here is my /etc/ipf.rules To me, this should be almost 'wide open'.


```
# block short packets
block in quick all with short

# block packets with IP options
block in quick all with ipopts

# loopback
pass in quick on lo0 all
pass out quick on lo0 all
```

Here is /etc/ipnat.rules:


```
map re0 0/0 -> 0/32 proxy port ftp ftp/tcp
map re0 0/0 -> 0/32 portmap tcp/udp auto
map re0 0/0 -> 0/32
```

Again, to me, that looks to me as though it should allow just about anything.

I've Googled for hours over days to try and resolve this -- but come up empty. I still can't help thinking it must be something silly simple though.

Any help would be much appreciated. Thanks.


----------



## SirDice (Nov 10, 2011)

You can't connect to your internet address from within your LAN. Test from outside your network.


----------



## pbd (Nov 10, 2011)

SirDice said:
			
		

> You can't connect to your internet address from within your LAN. Test from outside your network.



Really? I think it doesn't matter to which interface is the IP address assigned. In other words, I think you can connect to IP adress assigned to interface *A* even if the connection comes from client connected through interface *B* (sorry, I cannot verify that now).


----------



## SirDice (Nov 10, 2011)

pbd said:
			
		

> Really? I think it doesn't matter to which interface is the IP address assigned. In other words, I think you can connect to IP adress assigned to interface *A* even if the connection comes from client connected through interface *B* (sorry, I cannot verify that now).



Normally it doesn't matter but NAT is throwing a spanner in the works.


----------



## gruvin (Nov 11, 2011)

Thanks for the replies.

I'm not trying to connect to my internet address from inside my LAN. That would just be silly. Sorry, should have clarified in original post.

I'm AM testing from "outside" -- specifically via 3G cellular connection from my MacBook.

I've also figured out that if I add this to ipnat.rules ...

```
rdr re0 0/0 port 8xxx -> 127.0.0.1 port 8xxx tcp
```

... then it works. (Why I'm bothering to obscure the last 3 digits, who knows. Habit. )

(Couldn't post this earlier because my OP had not passed moderation.)

But why on earth should I have to redirect traffic that's already arriving on a local interface? Does this flavour of NAT offered by IPF not automatically DMZ the local interface, like every other NAT system does? I mean, change the incoming packet destination address to localhost. Isn't that what 'all' the other NAT systems do?

Also, when I try to redirect to my LAN interface like so ...

```
rdr re0 0/0 port 8xxx -> 192.168.1.1 port 8xxx tcp
```

... it doesn't work. 

But port redirects to other hosts on the LAN (192.168.1.2 for EG) do work just fine.

I've used various flavours of NAT for years. I've never come across a case where I had to manually specify 'pinholes' like this -- and certainly not to the loopback interface to get it to work. 

No, I must be missing something or doing something wrong.


----------



## gruvin (Nov 11, 2011)

Oh ... I shouldn't have said., 'have to pinhole'. I can direct all incoming traffic, like so ...

```
rdr re0 0/0 -> 127.0.0.1
```

I just figured, since I have to provide a manual redirect, I might as well lock it down to only what I needed. Hmmm. Perhaps that's it. Perhaps ipnat is designed for the security paranoid and this is all very much in purpose?


----------

