Re: problems with tftp-proxy in 11.1?
On 14 Dec 2017, at 8:16, Kristof Provost wrote:
On 7 Dec 2017, at 18:02, John Jasen wrote:
On Wed, Dec 6, 2017 at 5:01 PM, Kristof Provost
wrote:
On 6 Dec 2017, at 21:25, John Jasen wrote:
On 12/04/2017 02:47 PM, Kristof Provost wrote:
Okay, so this is interesting:
25013: ioctl(4,0xc04c4417 { IORW 0x44('D'), 23, 76 },0x7fffe5b0)
ERR#2
'No such file or directory'
The DIOCNATLOOK ioctl() fails with ENOENT, which happens if the
state
can’t be found.
Of course, I have no idea why that would happen. Does this affect
some
tftp connections or all of them?
Some, where the amount seems somewhat random.
I *think* I’ve reproduced this. It seems to happen only to the first
tftp packet, but at least that’s something to go on. I’ll try to
investigate further soon.
Do you have ‘set skip on lo0’ set by any chance?
I only see issues with that set, not once I unset it.
Regards,
Kristof
___
freebsd-pf@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
[Bug 193568] PF rdr rule with ipv6 does not work
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193568 --- Comment #5 from Alan Somers --- Created attachment 190002 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=190002&action=edit Fix RDR rules that redirect to ::1 "Fix" pf rdr rules with ::1 targets Redirecting an IPv6 packet to ::1 is a violation of IPv6 scoping rules, because ::1 only has node-local scope. It's supposed to be used only for traffic the begins and ends on a single node. Plus, it's a bad practice security-wise (server processes are often bound to ::1 as a deliberate way to prevent them from talking to the outside world), and it doesn't work on multihomed, single-fib hosts (the reply packet doesn't know which interface to use if its destination is non-local). However, the same arguments apply to IPv4, and FreeBSD already has hacks to make it work there. So I'm extending those hacks to IPv6. Even with this "fix", rdr won't work for packets destined to a link-local (ff80::*) address, because pf doesn't know how to set the embedded scope identifier on the reply packets. A better solution would be to configure pf to only redirect a packet's port, not its address and port. However, pf doesn't currently have that capability. netinet6/ip6_input.c In ip6_input, don't reject a packet with bad scope if the firewall has changed the destination address. ip_input does something similar with the "dchg" variable. sys/netinet6/ip6_output.c In ip6_output, don't fail a packet immediately if the scope check fails. Instead, repeat the scope check after running it through the firewall, if the firewall changed either the src or dst address. ip_output simply does the scope checking after the firewall. However, ip6_output can't do that, because at that point multicast packets will have inconsistent embedded scope identifiers. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-pf@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
