Please help me, if possible, with such problem.
There is a server in LAN with two interfaces in two subnets. It is necessary to create jails, which are placed in different subnets.
There are no restrictions on the interaction between networks, just the jails have IP in these two subnets.
I got stumped on the problem of ensuring the correct operation of FTP of those jails (REVERSE ftp-proxy) via the firewall PF (FreeBSD 10.3). I tried everything but without success.
Everything works fine within the communications on port 21 (command mode). But as soon as there is a switch to "Passive Mode" for data transfer (e.g. "ls" command), arise a very long delay. Everything works, but only in a few minutes.
I have read and tried all tutorials, but they do not provide for such a case.
http://dant.net.ru/calomel/ftp_proxy.html
http://www.openbsd.org/faq/pf/ftp.html#server
https://home.nuug.no/~peter/pf/en/ftpproblem.html
For testing purposes I have simplified the schematic up to one interface and one jail. I test FTP from the same subnet where jail.
Now I use this configuration for PF (in the latest experiments I have opened ports greater than 1023, although it changed nothing):
The firewall rules are displayed as:
I'm attaching a dump of the packets at the time of submitting of command "ls":
It seems nothing is blocked, but not running.
I tried ftpsesame, but it doesn't change anything.
This rule doesn't change anything too:
Everything works fine only when I turn off PF, or when set full permission of the traffic to the jail:
There is a server in LAN with two interfaces in two subnets. It is necessary to create jails, which are placed in different subnets.
There are no restrictions on the interaction between networks, just the jails have IP in these two subnets.
I got stumped on the problem of ensuring the correct operation of FTP of those jails (REVERSE ftp-proxy) via the firewall PF (FreeBSD 10.3). I tried everything but without success.
Everything works fine within the communications on port 21 (command mode). But as soon as there is a switch to "Passive Mode" for data transfer (e.g. "ls" command), arise a very long delay. Everything works, but only in a few minutes.
I have read and tried all tutorials, but they do not provide for such a case.
http://dant.net.ru/calomel/ftp_proxy.html
http://www.openbsd.org/faq/pf/ftp.html#server
https://home.nuug.no/~peter/pf/en/ftpproblem.html
For testing purposes I have simplified the schematic up to one interface and one jail. I test FTP from the same subnet where jail.
Now I use this configuration for PF (in the latest experiments I have opened ports greater than 1023, although it changed nothing):
Code:
# ftp-proxy -R 10.48.41.81 -P 21
# I tried to use packet tagging, but it doesn't help.
# Extended logging ftp-proxy also does nothing.
iface_2="vlan0"
set skip on { lo0, lo1, lo2 }
scrub in all
nat-anchor "ftp-proxy/*"
rdr-anchor "ftp-proxy/*"
rdr pass on $iface_2 proto tcp from any to 10.48.41.81 port 21 -> 127.0.0.1 port 8021
anchor "ftp-proxy/*"
pass in quick log on $iface_2 inet proto tcp from any to 127.0.0.1 port 8021
# It was recommended here: http://dant.net.ru/calomel/ftp_proxy.html But it didn't help.
pass in quick log on $iface_2 inet proto tcp from any to 10.48.41.81 port 21
pass in quick log on $iface_2 proto tcp from any to 10.48.41.81 port > 1023
pass out quick all
block drop in all
The firewall rules are displayed as:
Code:
@1 nat-anchor "/*" all
@2 rdr-anchor "/*" all
@3 rdr pass on vlan0 inet proto tcp from <int_net:0> to 10.48.41.81 port = ftp -> 127.0.0.1 port 8021
………………………
@32 anchor "/*" all
@33 pass in log quick on vlan0 inet proto tcp from <int_net:0> to 10.48.41.81 port = ftp flags S/SA keep state
@34 pass in log quick on vlan0 inet proto tcp from any to 10.48.41.81 port > 1023 flags S/SA keep state
@35 pass in log quick on vlan0 inet proto tcp from any to 127.0.0.1 port = ftp-proxy flags S/SA keep state
@36 pass out quick all flags S/SA keep state
@37 block drop in all
I'm attaching a dump of the packets at the time of submitting of command "ls":
Code:
13:21:13.090836 00:50:56:a8:0c:9b > 3c:a8:2a:0a:4d:7d, ethertype IPv4 (0x0800), length 74: 10.48.41.197.63670 > 10.48.41.81.21: Flags [P.], seq 487664651:487664659, ack 1176357923, win 1040, options [nop,nop,TS val 488596182 ecr 3070076677], length 8
13:21:13.091037 3c:a8:2a:0a:4d:7d > 00:50:56:a8:0c:9b, ethertype IPv4 (0x0800), length 89: 10.48.41.81.21 > 10.48.41.197.63670: Flags [P.], seq 1:24, ack 8, win 1040, options [nop,nop,TS val 3070102204 ecr 488596182], length 23
13:21:13.092517 00:50:56:a8:0c:9b > 3c:a8:2a:0a:4d:7d, ethertype IPv4 (0x0800), length 72: 10.48.41.197.63670 > 10.48.41.81.21: Flags [P.], seq 8:14, ack 24, win 1040, options [nop,nop,TS val 488596182 ecr 3070102204], length 6
13:21:13.092952 3c:a8:2a:0a:4d:7d > 00:50:56:a8:0c:9b, ethertype IPv4 (0x0800), length 114: 10.48.41.81.21 > 10.48.41.197.63670: Flags [P.], seq 24:72, ack 14, win 1040, options [nop,nop,TS val 3070102206 ecr 488596182], length 48
13:21:13.094127 00:50:56:a8:0c:9b > 3c:a8:2a:0a:4d:7d, ethertype IPv4 (0x0800), length 74: 10.48.41.197.63691 > 10.48.41.81.56265: Flags [SEW], seq 2262204441, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 488596182 ecr 0], length 0
13:21:13.094168 3c:a8:2a:0a:4d:7d > 00:50:56:a8:0c:9b, ethertype IPv4 (0x0800), length 74: 10.48.41.81.56265 > 10.48.41.197.63691: Flags [S.E], seq 839468741, ack 2262204442, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 1193070092 ecr 488596182], length 0
13:21:13.095635 00:50:56:a8:0c:9b > 3c:a8:2a:0a:4d:7d, ethertype IPv4 (0x0800), length 66: 10.48.41.197.63691 > 10.48.41.81.56265: Flags [.], ack 1, win 1040, options [nop,nop,TS val 488596182 ecr 1193070092], length 0
13:21:13.095662 00:50:56:a8:0c:9b > 3c:a8:2a:0a:4d:7d, ethertype IPv4 (0x0800), length 72: 10.48.41.197.63670 > 10.48.41.81.21: Flags [P.], seq 14:20, ack 72, win 1040, options [nop,nop,TS val 488596182 ecr 3070102206], length 6
13:21:13.095760 3c:a8:2a:0a:4d:7d > 00:50:56:a8:0c:9b, ethertype IPv4 (0x0800), length 66: 10.48.41.81.56265 > 10.48.41.197.63691: Flags [F.], seq 1, ack 1, win 1023, options [nop,nop,TS val 1193070094 ecr 488596182], length 0
13:21:13.096725 00:50:56:a8:0c:9b > 3c:a8:2a:0a:4d:7d, ethertype IPv4 (0x0800), length 66: 10.48.41.197.63691 > 10.48.41.81.56265: Flags [.], ack 2, win 1040, options [nop,nop,TS val 488596182 ecr 1193070094], length 0
13:21:13.106163 3c:a8:2a:0a:4d:7d > 00:50:56:a8:0c:9b, ethertype IPv4 (0x0800), length 66: 10.48.41.81.21 > 10.48.41.197.63670: Flags [.], ack 20, win 1040, options [nop,nop,TS val 3070102219 ecr 488596182], length 0
^C
11 packets captured
It seems nothing is blocked, but not running.
I tried ftpsesame, but it doesn't change anything.
This rule doesn't change anything too:
Code:
pass in quick log on $iface_2 inet proto tcp from any port > 1023 to any port > 1023
Everything works fine only when I turn off PF, or when set full permission of the traffic to the jail:
Code:
pass in quick log on $iface_2 inet proto tcp from any to 10.48.41.81