Unless the bridge keeps stateful inspection data and can reply back to
the session's origin, not it route then its fine.
The only way I can see this working is either putting the FTP/.. DMZ
behind the firewall giving true firewall protection for all services
involved, or if you just want to kludge the current solution, you can
perform a DNAT/SNAT interface bounce like the following:
# Session
iptables -A PREROUTING --destination ${FAKE_FTP_IP} -p tcp --dport 21 -j
MARK 1234
iptables -A PREROUTING --destination ${FAKE_FTP_IP} -p tcp --dport 21 -j
DNAT ${MY_FTP_SERVER}
iptables -A POSTROUTING -m mark 1234 -j SNAT --to ${MY_INTERNAL_IP}
The above should work for single channel TCP/IP traffic, but I don't
know if more is needed for multi-session FTP. The RELATED streams may be
handled automatically in the NAT code, or you may have to explicitly
place rules into the code.
Of course, the identity of the FTP user can't be tracked on the FTP
server since they all appear to be coming from the firewall in question.
_______________________________________________
LARTC mailing list / LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
