On 14/6/18 1:41 am, Michael Sierchio wrote:
I see you have a case of Netgraph. Perhaps Julian will chime in.
well I'm reading but not got any specific ideas at the moment..
Netgraph itself has no requirements on packet size or even contents.
a node may however have some.
On Wed, Jun 13, 2018 at 10:32 AM, Jeff Kletsky <free...@wagsky.com> wrote:
On 6/13/18 10:22 AM, Michael Sierchio wrote:
On Wed, Jun 13, 2018 at 10:16 AM, Jeff Kletsky <free...@wagsky.com> wrote:
When a T-Mobile "femto-cell" is trying to establish its IPv4, IPSEC tunnel
to the T-Mobile provisioning servers, the reassembled, 4640-byte return
packet is silently dropped by the in-kernel NAT, even though it "matches"
the outbound packet from less than 100 ms prior.
Do you have a 'reass' rule before applying nat on inbound traffic?
- M
Yes, at the start of the rule set.
Reassembly confirmed to be working by wireshark examination of the ngtee
"taps" shown
$ sudo ipfw list
00001 deny ip from any to any recv ng*
00004 ngtee 100 ip from any to any proto udp dst-port 500,4500 in
00004 ngtee 100 ip from any to any proto udp frag in
00004 ngtee 110 ip from any to any proto udp dst-port 500,4500 out
00004 ngtee 110 ip from any to any proto udp frag out
00005 reass ip from any to any
00006 ngtee 101 ip from any to any proto udp dst-port 500,4500 in //
reassembled in
00006 ngtee 101 ip from any to any proto udp frag in // never should be
frags after reass
00006 ngtee 111 ip from any to any proto udp dst-port 500,4500 out //
reass out
00006 ngtee 111 ip from any to any proto udp frag out // never should be
frage after reass
[...]
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
