A STATEFUL firewall with ?ip any any? can and will still block asymmetric communications due to the firewall keeping track of state (hence tha name stateful firewall). Tcpdump on your servers /other/ NICs and you?ll see the tftp traffic leaving your server on some other NIC (probably on with the default route). The upstream firewall will then block the tftp response if it never saw the tftp request (due to asymmetry).
On Thu, Mar 29, 2018 at 7:21 AM, Steven Tardy <sjt5atra at gmail.com> wrote:> A STATEFUL firewall with ?ip any any? can and will still block asymmetric > communications due to the firewall keeping track of state (hence tha name > stateful firewall). > > Tcpdump on your servers /other/ NICs and you?ll see the tftp traffic > leaving your server on some other NIC (probably on with the default route). >A (192.168.1.10) S (192.168.1.20) I do not see tftp traffic is leaving from S A:~$ tftp (to) 192.168.1.20 tftp> get file Transfer timed out. As you can see no pkt is leaving. If it were leaving S, but A were not receiving then I would think firewall is dropping it. [ S ~]$ sudo tcpdump -A -nniany host 192.168.1.10 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 16:40:08.390939 IP 192.168.1.10.35553 > 192.168.1.20.69: 16 RRQ "file" netascii E..,J1 at .>..n./...oAt...E..#...file.netascii................... 16:40:13.391133 IP 192.168.1.10.35553 > 192.168.1.20.69: 16 RRQ "file" netascii E..,N. at .>..../...oAt...E..#...file.netascii................... 16:40:18.391220 IP 192.168.1.10.35553 > 192.168.1.20.69: 16 RRQ "file" netascii E..,QK at .>..T./...oAt...E..#...file.netascii................... 16:40:23.391373 IP 192.168.1.10.35553 > 192.168.1.20.69: 16 RRQ "file" netascii E..,T^@.>.. at ./...oAt...E..#...file.netascii................... 16:40:28.391469 IP 192.168.1.10.35553 > 192.168.1.20.69: 16 RRQ "file" netascii E..,X. at .>..../...oAt...E..#...file.netascii...................> > The upstream firewall will then block the tftp response if it never saw the > tftp request (due to asymmetry). > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >-- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
On Thu, Mar 29, 2018 at 12:48 PM, Asif Iqbal <vadud3 at gmail.com> wrote:> > > On Thu, Mar 29, 2018 at 7:21 AM, Steven Tardy <sjt5atra at gmail.com> wrote: > >> A STATEFUL firewall with ?ip any any? can and will still block asymmetric >> communications due to the firewall keeping track of state (hence tha name >> stateful firewall). >> >> Tcpdump on your servers /other/ NICs and you?ll see the tftp traffic >> leaving your server on some other NIC (probably on with the default >> route). >> > > A (192.168.1.10) > S (192.168.1.20) > > I do not see tftp traffic is leaving from S > > A:~$ tftp > (to) 192.168.1.20 > tftp> get file > Transfer timed out. > > As you can see no pkt is leaving. If it were leaving S, but A were not > receiving then I would think firewall > is dropping it. > > [ S ~]$ sudo tcpdump -A -nniany host 192.168.1.10 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 > bytes > > 16:40:08.390939 IP 192.168.1.10.35553 > 192.168.1.20.69: 16 RRQ "file" > netascii > E..,J1 at .>..n./...oAt...E..#...file.netascii................... > 16:40:13.391133 IP 192.168.1.10.35553 > 192.168.1.20.69: 16 RRQ "file" > netascii > E..,N. at .>..../...oAt...E..#...file.netascii................... > 16:40:18.391220 IP 192.168.1.10.35553 > 192.168.1.20.69: 16 RRQ "file" > netascii > E..,QK at .>..T./...oAt...E..#...file.netascii................... > 16:40:23.391373 IP 192.168.1.10.35553 > 192.168.1.20.69: 16 RRQ "file" > netascii > E..,T^@.>.. at ./...oAt...E..#...file.netascii................... > 16:40:28.391469 IP 192.168.1.10.35553 > 192.168.1.20.69: 16 RRQ "file" > netascii > E..,X. at .>..../...oAt...E..#...file.netascii................... > > >I still like some help on this> > >> >> The upstream firewall will then block the tftp response if it never saw >> the >> tftp request (due to asymmetry). >> _______________________________________________ >> CentOS mailing list >> CentOS at centos.org >> https://lists.centos.org/mailman/listinfo/centos >> > > > >-- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
On Thu, Mar 29, 2018 at 12:48:15PM -0400, Asif Iqbal wrote:> I do not see tftp traffic is leaving from S > > A:~$ tftp > (to) 192.168.1.20 > tftp> get file > Transfer timed out. > > As you can see no pkt is leaving. If it were leaving S, but A were not > receiving then I would think firewall > is dropping it. > > [ S ~]$ sudo tcpdump -A -nniany host 192.168.1.10 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 > bytesMost likely the firewall on the system running your tftp client is blocking the traffic from the tftp server. The easiest way to test would be to put in a rule that allows all packets from the server (or to at least log them so you can see what's happening). The firewall issue is most likely *not* with the tftp server. -- Jonathan Billings <billings at negate.org>