dslreports logo
 
    All Forums Hot Topics Gallery
spc
uniqs
32

Gork
Ou812ic
join:2001-10-06
Bountiful, UT

4 edits

Gork to Brano

Member

to Brano

Re: Replaced 2WG with USG20W

Brano See Profile: I just updated my post to indicate acknowledgement for your earlier contribution in this thread regarding this issue.

It seems easy enough to set up, and I assume it would automatically create any necessary fw and NAT rules "on the fly?" However, my suggestion to the op, since he is having trouble, is to manually get FTP working to ensure the process is understood then try switching over to using server side FTP ALG.

ACTV/PASV FTP was the biggest pain for me to learn back when I was first learning about connections and ports. But when I FINALLY figured it out it was truly a "duh'oh moment." But it certainly is a very weird "protocol."

EDIT:
The site you linked, Brano See Profile, is the very site I breezed over to refresh my memory. It is not ZyXEL specific. And I am quite sure that client side FTP ALG is much more common than server-side, if server-side FTP ALG even exists. Without client-side FTP ALG a client behind a NAT device and/or firewall would be blocked from ever initiating any ACTV FTP connection with an FTP server.

The site linked doesn't specifically discuss ALG but does seem to indicate what I have described with regard to ACTV connections:
quote:
The main problem with active mode FTP actually falls on the client side. The FTP client doesn't make the actual connection to the data port of the server--it simply tells the server what port it is listening on and the server connects back to the specified port on the client. From the client side firewall this appears to be an outside system initiating a connection to an internal client--something that is usually blocked.
Gork

Gork

Member

Continued:

In looking at the GUI on my USG20W it doesn't appear the FTP ALG section is anything different than what I've seen before; it appears to be for client side connections from behind the USG to an ACTV FTP server on the WAN side. So unless there's something else built into the USG to handle server side "FTP ALG" and/or another related page on the GUI for the USG besides Configuration -> Network -> ALG it appears to me the FTP ALG in the USG is for clients behind the USG, not for servers behind the USG. (I guess there's a third option, that I may be confused about something related to the USG itself. I'm certainly not in the same league as others in this forum.)

Anav
Sarcastic Llama? Naw, Just Acerbic
Premium Member
join:2001-07-16
Dartmouth, NS

Anav

Premium Member

I use FTP behind the zywall with no issues following Branos advice.

If dydns is setup properly (associated with the WANIP of the op)
If the port forwarding rule allows access to all to the PC serving the FTP
If the firewall rule allows access to (all or specific WANIP or range of WANIPs) to the pc serving the FTP.

Then it should work.

+++++++++++++++++++++

Right now I fail the grc test because 443 is exposed but it does note that the port is closed.

Under System for Admin control
I have a non standard port selected, I do not redirect http to https.
Not sure what was there originally for zones, but the ALL ALL accept rule is still at the bottom (assuming default and I dont muck with those). On top of that I have all the zones as all all accept (tunnel, lan1,2,dmz,). Just below that, in between the zones and the default rule I have one just for WAN that is all all DENY.

In other words, no access to management of router from WAN side.
(I guess, one could access from an L2TP tunnel the way I have this setup).

In other words my 443 exposure has nothing to do at this point with my admin SYS rules setup. So its in default rules and checking yes its in the Wan to Zywall default rulese (Default_allow_Wan_to_Zywall). Checking this under Object Service Group......... AH, ESP, GRE, HTTPS, IKE, NATT and VRRP are all on the default list.

Since I personally have had bad karma touching default rules, if I wanted to block the https (443) service from being open, I would simply ensure a wan to zywall rule just before the default rule (blocking https.)
Note that using the word reject still shows the port as visible but not open. By using the word DENY, grc no longer even sees the port.

So its fairly easy to ensure 443 is not visible at all. The question I have is do I need natt and vrrp at all. Dont know what they are for and dont think ive ever used them (ah, esp, ike being ipsec related, forget what gre is for). Next post will work on ping
Anav

Anav

Premium Member

Okay making router pingable. Note this is not required for successful FTP but perhaps it is helpful.

I will assume this is also a wan to zywall firewall rule entitiy.
In older routers there were shenanigans in the security side of the house beside firewall rule (two places required to manipulate ping).

I found (on my list #64) a service called PING, its IP protoco is ICMP and its ICMP Type is echo. Added this as a Wan to zywall rule and quickly failed grc test, 3rd sentence just above the ports table stated.......

Ping is just to the router, not to the PC with the FTP server.

Ping Reply: RECEIVED (FAILED) — Your system REPLIED to our Ping (ICMP Echo) requests, making it visible on the Internet. Most personal firewalls can be configured to block, drop, and ignore such ping requests in order to better hide systems from hackers. This is highly recommended since "Ping" is among the oldest and most common methods used to locate systems prior to further exploitation.

So making it pingable seems fairly easy, not quite sure what you were trying to do....... . In your case turn it on plus the logging and also for your firewall rule for FTP, just to see if your friend actually reaches the router to any degree.

Brano
I hate Vogons
MVM
join:2002-06-25
Burlington, ON
(Software) OPNsense
Ubiquiti UniFi UAP-AC-PRO
Ubiquiti NanoBeam M5 16

Brano to Gork

MVM

to Gork
said by Gork:

And I am quite sure that client side FTP ALG is much more common than server-side, if server-side FTP ALG even exists.

I've tested accessing FTP both ways with FTP server being behind USG or on WAN side, both active and passive connectivity.
The FTP_ALG works on both, so short answer would be it's both client and server FTP_ALG.

TheJoker
MVM
join:2001-04-26
Charlottesville, VA

TheJoker

MVM

Still can't figure out what is wrong. My external user can't even ping, it just times out for him, and I get no log entry.

I have 3 port forwarding rules, one for the higher FTP signalling port, one for the PASV range, and one for FTP service. All were set as:
Incoming Interface: wan1
Original IP: Object-External-User_IP
Mapped IP: Object-My_workstation_IP
Port Mapping Type: Port
Protocol Type: any

For the signaling port:
Original Port: 2345 (nominally)
Mapped Port: 2345

For the PASV range:
Original Start Port: 3456 (nominally)
Original End Port: 3465
Mapped Start Port:3456
Mapped End Port:3465

And for the Standard FTP port:
Port Mapping Type: Service
Original Service: FTP
Mapped Service: FTP

I have an added firewall rule at top:
Enable
From: WAN
To: LAN1
Description: Custom_Forward
Schedule: none
User: any
Source: Object-External-User_IP
Destination: Object-My_workstation_IP
Service: any
Access: allow
Log: log

All had NAT loopback enabled. He cannot connect, and there is no log entry

I've changed the rule to allow to any destination, and had a warning that I had to turn NAT loopback off for that, and did so. Waiting to see if he can successfully connect.

I have two other firewall rules, one to allow GRC to ping, and one to allow him to ping. The rule for GRC works, the rule for him to ping doesn't, and again no log entry.

Brano
I hate Vogons
MVM
join:2002-06-25
Burlington, ON

Brano

MVM

In addition to all of above, keep in mind that firewall rules are evaluated from top to bottom and first match is applied and no additional rules are evaluated. The order of rules is important.