Re: IPFW NAT behaviour different on 10-Stable versus 11-Stable [SOLVED]

2017-09-02 Thread Graham Menhennitt 

On 02/09/2017 20:46, Ian Smith wrote:

On Sat, 2 Sep 2017 11:44:51 +1000, Graham Menhennitt wrote:

  > I have a problem that seems to be a difference between ipfw/NAT
  > behaviour in 10-Stable versus 11-Stable. I have two servers: one running
  > 10-Stable and one running 11-Stable. I'm using the same rule set on both
  > (see below). It works correctly on 10-Stable but not on 11.
  >
  > The problem is seen on two places: an outgoing SMTP connection on port
  > 465, and an incoming to an IMAP server on port 993. In both cases, there
  > are lost packets and retransmissions. See below for a tshark capture of
  > one attempted SMTP session.
  >
  > Setting sysctl net.inet.ip.fw.one_pass to one or zero makes no
  > difference. Deleting the sshguard rule (table 22) makes no difference.
  > Deleting the nat rule makes everything work for this SMTP session (but
  > breaks the other machines on my network obviously).
  >
  > I have no doubt that I have misconfigured the firewall, but I don't see
  > what. And why is 11 different to 10? Any help would be much appreciated.
  >
  > Thanks in advance,
  >
  >  Graham

Mysterious.  Unless this is some other networking issue, three thoughts:

1) given that YYY is your public IP address, are the problematic SMTP
sessions actually going through NAT at all, or are they initiated from
YYY directly?  If the latter, it's hard to see why removing the NAT rule
should affect these session at all?

2) does it make any difference if you split the NAT rules into separate
rules, as per the ipfw(8) 'NAT, REDIRECT AND LSNAT' section in EXAMPLES?

3) given the tokens used in your ruleset, it appears that you are using
a preproceesor to substitute values rather than shell variables?  If so
(or even if not) can you confirm that the resulting in-place rulesets
shown by 'ipfw list' are absolutely identical on both machines?

Just some long shots ..

cheers, Ian


Thanks for replying, Ian.

Well I solved it. Similarly to my previous problem, the solution was to 
disable the TXCSUM option on the interface. So, now the entry in 
/etc/rc.conf says:


ifconfig_igb1="DHCP -vlanhwtso -tso4 -txcsum"

And it all works.

Thanks again,

Graham

___
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"

Re: IPFW NAT behaviour different on 10-Stable versus 11-Stable

2017-09-02 Thread Ian Smith 
On Sat, 2 Sep 2017 11:44:51 +1000, Graham Menhennitt wrote:

 > I have a problem that seems to be a difference between ipfw/NAT 
 > behaviour in 10-Stable versus 11-Stable. I have two servers: one running 
 > 10-Stable and one running 11-Stable. I'm using the same rule set on both 
 > (see below). It works correctly on 10-Stable but not on 11.
 > 
 > The problem is seen on two places: an outgoing SMTP connection on port 
 > 465, and an incoming to an IMAP server on port 993. In both cases, there 
 > are lost packets and retransmissions. See below for a tshark capture of 
 > one attempted SMTP session.
 > 
 > Setting sysctl net.inet.ip.fw.one_pass to one or zero makes no 
 > difference. Deleting the sshguard rule (table 22) makes no difference. 
 > Deleting the nat rule makes everything work for this SMTP session (but 
 > breaks the other machines on my network obviously).
 > 
 > I have no doubt that I have misconfigured the firewall, but I don't see 
 > what. And why is 11 different to 10? Any help would be much appreciated.
 > 
 > Thanks in advance,
 > 
 >  Graham

Mysterious.  Unless this is some other networking issue, three thoughts:

1) given that YYY is your public IP address, are the problematic SMTP 
sessions actually going through NAT at all, or are they initiated from 
YYY directly?  If the latter, it's hard to see why removing the NAT rule 
should affect these session at all?

2) does it make any difference if you split the NAT rules into separate 
rules, as per the ipfw(8) 'NAT, REDIRECT AND LSNAT' section in EXAMPLES?

3) given the tokens used in your ruleset, it appears that you are using 
a preproceesor to substitute values rather than shell variables?  If so 
(or even if not) can you confirm that the resulting in-place rulesets 
shown by 'ipfw list' are absolutely identical on both machines?

Just some long shots ..

cheers, Ian
___
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"

IPFW NAT behaviour different on 10-Stable versus 11-Stable

2017-09-01 Thread Graham Menhennitt 
I have a problem that seems to be a difference between ipfw/NAT 
behaviour in 10-Stable versus 11-Stable. I have two servers: one running 
10-Stable and one running 11-Stable. I'm using the same rule set on both 
(see below). It works correctly on 10-Stable but not on 11.


The problem is seen on two places: an outgoing SMTP connection on port 
465, and an incoming to an IMAP server on port 993. In both cases, there 
are lost packets and retransmissions. See below for a tshark capture of 
one attempted SMTP session.


Setting sysctl net.inet.ip.fw.one_pass to one or zero makes no 
difference. Deleting the sshguard rule (table 22) makes no difference. 
Deleting the nat rule makes everything work for this SMTP session (but 
breaks the other machines on my network obviously).


I have no doubt that I have misconfigured the firewall, but I don't see 
what. And why is 11 different to 10? Any help would be much appreciated.


Thanks in advance,

Graham


Tshark:

(XXX is the SMTP server, YYY is my public IP address)

root# tshark -Y tcp.port==465 -i igb1
Capturing on 'igb1'
4   0.722919 YYY → XXX TLSv1.2 180 Client Key Exchange, Change 
Cipher Spec, Encrypted Handshake Message
  527  17.822843 YYY → XXX TCP 180 [TCP Retransmission] 63024 → 465 
[PSH, ACK] Seq=1 Ack=1 Win=65535 Len=126
 1335  51.814540 YYY → XXX TCP 180 [TCP Retransmission] 63024 → 465 
[PSH, ACK] Seq=1 Ack=1 Win=65535 Len=126
 1393  85.806537 YYY → XXX TCP 180 [TCP Retransmission] 63024 → 465 
[PSH, ACK] Seq=1 Ack=1 Win=65535 Len=126
 2142 107.799346 XXX → YYY TCP 60 465 → 63024 [FIN, ACK] Seq=1 Ack=1 
Win=15544 Len=0
 2143 107.799393 YYY → XXX TCP 54 63024 → 465 [ACK] Seq=127 Ack=2 
Win=65535 Len=0
 2144 107.800135 YYY → XXX TCP 54 63024 → 465 [FIN, ACK] Seq=127 Ack=2 
Win=65535 Len=0
 2145 107.822047 YYY → XXX TCP 74 53762 → 465 [SYN] Seq=0 Win=65535 
Len=0 MSS=1460 WS=64 SACK_PERM=1 TSval=2591962 TSecr=0

 2146 107.977234 XXX → YYY TCP 60 465 → 63024 [RST] Seq=2 Win=0 Len=0
 2149 108.001214 XXX → YYY TCP 62 465 → 53762 [SYN, ACK] Seq=0 Ack=1 
Win=14600 Len=0 MSS=1460 SACK_PERM=1
 2150 108.001270 YYY → XXX TCP 54 53762 → 465 [ACK] Seq=1 Ack=1 
Win=65535 Len=0

 2151 108.009014 YYY → XXX TLSv1 323 Client Hello
 2160 108.187708 XXX → YYY TCP 60 465 → 53762 [ACK] Seq=1 Ack=270 
Win=15544 Len=0

 2176 108.687644 XXX → YYY TLSv1.2 1514 Server Hello
 2177 108.687884 XXX → YYY TCP 1514 465 → 53762 [PSH, ACK] Seq=1461 
Ack=270 Win=15544 Len=1460 [TCP segment of a reassembled PDU]
 2178 108.687949 YYY → XXX TCP 54 53762 → 465 [ACK] Seq=270 Ack=2921 
Win=62874 Len=0
 2179 108.688175 XXX → YYY TCP 1230 465 → 53762 [PSH, ACK] Seq=2921 
Ack=270 Win=15544 Len=1176 [TCP segment of a reassembled PDU]
 2180 108.704012 XXX → YYY TCP 1514 465 → 53762 [ACK] Seq=4097 Ack=270 
Win=15544 Len=1460 [TCP segment of a reassembled PDU]
 2181 108.704052 YYY → XXX TCP 54 53762 → 465 [ACK] Seq=270 Ack=5557 
Win=64240 Len=0
 2182 108.704625 XXX → YYY TLSv1.2 969 Certificate, Server Key 
Exchange, Server Hello Done
 2183 108.715222 YYY → XXX TLSv1.2 180 Client Key Exchange, Change 
Cipher Spec, Encrypted Handshake Message
 2211 109.133829 YYY → XXX TCP 180 [TCP Retransmission] 53762 → 465 
[PSH, ACK] Seq=270 Ack=6472 Win=65535 Len=126
 2238 109.443030 XXX → YYY TCP 969 [TCP Spurious Retransmission] 465 → 
53762 [PSH, ACK] Seq=5557 Ack=270 Win=15544 Len=915[Reassembly error, 
protocol TCP: New fragment overlaps old data (retransmission?)]
 2239 109.443099 YYY → XXX TCP 54 [TCP Dup ACK 2183#1] 53762 → 465 
[ACK] Seq=396 Ack=6472 Win=65535 Len=0
 2244 109.772021 YYY → XXX TCP 180 [TCP Retransmission] 53762 → 465 
[PSH, ACK] Seq=270 Ack=6472 Win=65535 Len=126
 2301 110.827331 YYY → XXX TCP 180 [TCP Retransmission] 53762 → 465 
[PSH, ACK] Seq=270 Ack=6472 Win=65535 Len=126
 2402 112.770796 YYY → XXX TCP 180 [TCP Retransmission] 53762 → 465 
[PSH, ACK] Seq=270 Ack=6472 Win=65535 Len=126
 2612 116.391551 YYY → XXX TCP 180 [TCP Retransmission] 53762 → 465 
[PSH, ACK] Seq=270 Ack=6472 Win=65535 Len=126
 2711 119.018591 YYY → XXX TCP 180 [TCP Retransmission] 53762 → 465 
[PSH, ACK] Seq=270 Ack=6472 Win=65535 Len=126
 2737 123.957850 YYY → XXX TCP 180 [TCP Retransmission] 53762 → 465 
[PSH, ACK] Seq=270 Ack=6472 Win=65535 Len=126
 2789 133.632511 YYY → XXX TCP 180 [TCP Retransmission] 53762 → 465 
[PSH, ACK] Seq=270 Ack=6472 Win=65535 Len=126
 2859 152.776509 YYY → XXX TCP 180 [TCP Retransmission] 53762 → 465 
[PSH, ACK] Seq=270 Ack=6472 Win=65535 Len=126

^C32 packets captured
root#


Rules:

# stop spoofing
add deny all from LAN_NET to any in via OUTSIDE_IF
add deny all from WIFI_NET to any in via OUTSIDE_IF

# allow anything on the LAN
add allow all from any to any via LAN_IF

# and from the VPN
add allow all from any to any via VPN_IF

# allow anything from the wireless network to the outside world (but not 
to the LAN)

add allow ip from any to not LAN_NET via WIFI_IF

# create a table of addresses to block
#table 1 destroy
#table 1 create type addr
table 1 flush
# add