Re: IPv6 NAT

[Jason Lewis]

Folks have said that IPv6 does not support NAT, so I believe they will
not be putting it into IPFW.  I do know that pf has supported IPv6 NAT
or NAT6 since 2006 and it has been working great for me for more than
five years.

On 4/30/16, Georgios Amanakis via freebsd-ipfw  wrote:
> Does anyone know if someone works on implementing IPv6 NAT (like IPv4
> NAT, not prefix translation only) in IPFW? As far as I can tell
> FreeBSD's pf has this functionality. Linux implemented this since
> kernel 3.9, too.
> ___
> 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"

Re: ipfw on just inbound and not outbound

[Jason Wolfe]

Ian,

It's not so much the induced latency, but the CPU usage.  Simply
invoking ipfw causes a noticeable amount of overhead, and with a
single rule it clocks in at 5% on the hardware in question.  This
ranks ipfw_chk in as the 2nd hungriest function, just below tcp_output
in the IRQ handler threads with a single rule.  With 3 rules, it
overtakes the top spot (each adding ~ .3% -.5%).

If there were an easy way to gain back that 5% on outbound traffic,
we'd gladly take it.  It sounds like being able to disconnect paths
from ipfw might be a science project for the future, though it does
seem it could garner some wider interest.

Jason

On Thu, Apr 16, 2015 at 12:12 AM, Ian Smith smi...@nimnet.asn.au wrote:
 On Thu, 16 Apr 2015 11:41:54 +0800, Julian Elischer wrote:
   On 4/15/15 5:09 AM, hiren panchasara wrote:
Apologies if this is something silly but I want to completely eliminate
ipfw from outgoing traffic perspective. I just want to have it on
incoming. I can always add allow ip from any to any out as the first
rule but that is still ipfw doing something.
   
Is there a way to tell ipfw to not look at outbound traffic at all?
   no
   
OR, the rule I mentioned is the best that can be done here?
   yes
  
   this touches on something I've been thinking of for a while.. per
   interface/direction rule sets.
   but that doesn't exist yet.
  
   you could write a kernel module that would disconnect the outgoing packet
   filter hooks
   but hack comes to mind as a description there.
  
   actually  you could use the ipfw netgraph hook and only hook it up for
   incoming packets,
   but it would probably be not much more efficient than just having the rule,
   and more complicated to set up.

 I'm wondering if the cost of that one rule is even worth worrying about.

 Hiren, you might try running iperf (ono):

  a) after 'ipfw disable firewall'

  b) after just 'ipfw add 2 allow ip from any to any'

  c) after say 1000 rules before getting to (b) by such as:

  for i in `jot - 0 999`; do
 ipfw add $((i*10+1000)) count ip from any to any
  done

 to then calculate a cost per rule.  Tens or hundreds of ns?

 Of course, whether that cost is significant depends on the sort of pps
 rates you're having (or hoping :) to deal with on the box in question ..

cheers,
Hiren
   
ps: Please keep me cc'd as I am not subscribed.

 cheers, Ian
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: [RFC][patch] Two new actions: state-allow and state-deny

[Jason Lewis]

The possible issue is is that once NAT changes the IP address and
possibly the port number, state tracking can no longer be applied.
AKA, the packet headers before the NAT is different than the packet
headers after.  This is why NAT needs to track the state instead of
ipfw.
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: IPFW tables, dummynet and IPv6

[Jason Hellenthal]

On Sun, Dec 18, 2011 at 03:58:30PM +0400, Alexander V. Chernikov wrote:
 Pawel Tyll wrote:
  Hi lists,
  
  Are there any plans to implement IPv6 tables in ipfw? It would seem
  that our gov. may want to force us into IPv6 in 6 months ;)
 I've got working implementation for IPv4+IPv6 and interface tables:
 
 15:56 [0] zfsbase# /usr/obj/usr/src/sbin/ipfw/ipfw table 2 list
 1.2.3.4/30 0
 2a02:978::/64 0
 
 
 15:16 [0] zfsbase# /usr/obj/usr/src/sbin/ipfw/ipfw table 4 list
 em4/em4 2
 vlan144/vlan144 1
 vlan145/vlan145 11000
 vlan146/vlan146 12000
 
 
 I plan to commit it today/tomorrow.
 8.2-S diff will be available, too
 

1;



-- 
;s =;
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Strange problem

[Jason Mattax]

I'm currently running 8.1-RELEASE-p2 and attempting to set up a firewall
with natd and ipfw. I was trying a more complicated ipfw script and had
some problems. I reduced my rule set to the smallest sets I could manage
to find the exact rule that causes problems. xl0 is my world facing
interface and re0 faces my internal network. The working ruleset is

$ipfw list

00050 allow ip from any to any via lo0
00100 divert 8668 log ip from any to any in via xl0
1 divert 8668 log ip from any to any out via xl0
10005 allow ip from any to any
65535 allow ip from any to any

With this I get a log containing

$tail ipfw.log
Feb 10 20:37:53 stilgar kernel: ipfw: 100 Divert 8668 TCP
192.168.0.15:60569 192.168.0.10:22 in via xl0
Feb 10 20:37:54 stilgar kernel: ipfw: 100 Divert 8668 TCP
192.168.0.15:60569 192.168.0.10:22 in via xl0
Feb 10 20:37:54 stilgar kernel: ipfw: 1 Divert 8668 TCP
192.168.0.10:22 192.168.0.15:60569 out via xl0
Feb 10 20:37:54 stilgar kernel: ipfw: 100 Divert 8668 TCP
192.168.0.15:60569 192.168.0.10:22 in via xl0
Feb 10 20:37:54 stilgar kernel: ipfw: 100 Divert 8668 TCP
192.168.0.15:60569 192.168.0.10:22 in via xl0
Feb 10 20:37:54 stilgar kernel: ipfw: 1 Divert 8668 TCP
192.168.0.10:22 192.168.0.15:60569 out via xl0
Feb 10 20:37:54 stilgar kernel: ipfw: 100 Divert 8668 TCP
192.168.0.15:60569 192.168.0.10:22 in via xl0
Feb 10 20:37:54 stilgar kernel: ipfw: 100 Divert 8668 TCP
192.168.0.15:60569 192.168.0.10:22 in via xl0
Feb 10 20:37:54 stilgar kernel: ipfw: 1 Divert 8668 TCP
192.168.0.10:22 192.168.0.15:60569 out via xl0
Feb 10 20:37:54 stilgar kernel: ipfw: 100 Divert 8668 TCP
192.168.0.15:60569 192.168.0.10:22 in via xl0

Both of the diverts are working and machines attached to the internal nic can 
communicate through the computer. Now because I would like to be able to drop 
some packets I'm going to add a skip, since eventually that will get me where I 
want to be. This just adds rule 00310 which skips over no rules all the time

$ipfw list
00050 allow ip from any to any via lo0
00100 divert 8668 log ip from any to any in via xl0
00310 skipto  log ip from any to any
1 divert 8668 log ip from any to any out via xl0
10005 allow ip from any to any
65535 allow ip from any to any

Now the log contains
$tail ipfw.log
Feb 10 20:36:45 stilgar kernel: ipfw: 100 Divert 8668 TCP
192.168.0.15:60569 192.168.0.10:22 in via xl0
Feb 10 20:36:45 stilgar kernel: ipfw: 310 SkipTo  TCP
192.168.0.15:60569 192.168.0.10:22 in via xl0
Feb 10 20:36:45 stilgar kernel: ipfw: 310 SkipTo  TCP
192.168.0.10:22 192.168.0.15:60569 out via xl0
Feb 10 20:36:45 stilgar kernel: ipfw: 100 Divert 8668 TCP
192.168.0.15:60569 192.168.0.10:22 in via xl0
Feb 10 20:36:45 stilgar kernel: ipfw: 310 SkipTo  TCP
192.168.0.15:60569 192.168.0.10:22 in via xl0
Feb 10 20:36:45 stilgar kernel: ipfw: 100 Divert 8668 TCP
192.168.0.15:60569 192.168.0.10:22 in via xl0
Feb 10 20:36:45 stilgar kernel: ipfw: 310 SkipTo  TCP
192.168.0.15:60569 192.168.0.10:22 in via xl0
Feb 10 20:36:45 stilgar kernel: ipfw: 310 SkipTo  TCP
192.168.0.10:22 192.168.0.15:60569 out via xl0
Feb 10 20:36:45 stilgar kernel: ipfw: 100 Divert 8668 TCP
192.168.0.15:60569 192.168.0.10:22 in via xl0
Feb 10 20:36:45 stilgar kernel: ipfw: 310 SkipTo  TCP
192.168.0.15:60569 192.168.0.10:22 in via xl0

Rules 100 and 310 are being hit, but rule 1 is no longer triggering. This 
means that my outgoing packets aren't having their source address rewritten so 
I don't get responses (and put unrouteable traffic on the internet.) Can anyone 
explain to me what I'm doing wrong here?

Jason Mattax








-- 
Jason Mattax
575-418-1791
jmat...@storytotell.org

___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Code release of ipfw NAT support for SCTP in FreeBSD-8

[Jason But]

The Centre for Advanced Internet Architectures (CAIA - 
http://caia.swin.edu.au)
is proud to announce the release of alias_sctp version 0.1, a SCTP NAT 
patch to

FreeBSD 8.x.


Alias_sctp provides SCTP NAT functionality to the ipfw/ipfw_nat/libalias 
suite.

It is part of the CAIA SONATA project (http://caia.swin.edu.au/urp/sonata).
The code has been intentionally kept as separate as possible from the base
modules to aid testing and debugging, and make it easier to port to other
systems.

This project has been made possible in part by a grant from the Cisco
University Research Program Fund at Community Foundation Silicon Valley.


We welcome and value feedback and comments.
Please forward feedback to [EMAIL PROTECTED] and [EMAIL PROTECTED]

Download patch from http://caia.swin.edu.au/urp/sonata/downloads.html

Features of alias_sctp version 0.1:

- Basic configuration through ipfw nat ... config commands.

- Forwarding of incoming SCTP associations through
 ipfw nat ... redirect_addr ... commands.

- A variety of log levels (currently #define, but sysctl in version 0.2).

- Stateful SCTP association management.

12345678901234567890123456789012345678901234567890123456789012345678901234567890
- Tested on single-homed hosts, but should work when the multi-homed 
host is on

 the global side of the NAT (same mechanism for address translation).

- Dynamic hash table size allocation (currently #define, but sysctl in
 version 0.2).

- Initial testing has been for up to 1 concurrent flows arriving and 
leaving

 at about 2000/second. Tested for periods of up to 72 hours.


Features in the pipline for further releases:

- Sysctl interface for logging, timeouts, hash table size.
 Status - mostly complete.

- Port forwarding and load sharing.
 Status - mostly complete.

- Support for, soon to be specified, enhancements of SCTP to aid 
interworking

 with NATs.

- New AddIP ASCONF chunks.
 Status - preliminary coding and investigation.
 (Requires finalised standards to be completed)

- AbortM and ErrorM NAT originated messages.
 Status - preliminary coding, with work starting on the ipfw send interface

- IPv6 support.
 Status - preliminary investigation.

- Global IP address tracing.
 Status - preliminary investigation.


Other tasks:

- Exaustive testing of the various configurations and scenarios.

- Stress and load testing.

- Performance analysis.

Jason
--

--
Dr. Jason But
Lecturer
Telecommunications Engineering Academic Group
Faculty of Information and Communication Technologies
Swinburne University of Technology
http://www.swinburne.edu.au/ict/telecommshome.htm



___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]

RE: IPFW Problem

[Jason Lewis]

Greg,

My guess would be to look at rule 00800.  I suspect that the network that
you are having problems with is on BGE0.  NAT and keep-state do not play
well with each other.

Jason

On Sun, November 4, 2007 4:14 pm, [EMAIL PROTECTED] wrote:
 Hmm, I may well be missing something very obvious but rule 01000 seems
 to be doing exactly what it says it will.  Are you sure you meant deny
 rather than allow on rule 01000 ? It seems very unfreindly to allow
 outgoing TCP connections and then the minute they are established deny
 any return traffic !! Usually the established test is there to detect
 valid incoming traffic associated with your own outgoing safe
 connections.

 Cheers

 John

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of ext Gardner Bell
 Sent: Sunday, November 04, 2007 8:51 AM
 To: freebsd-ipfw@freebsd.org
 Subject: IPFW Problem

 I'm hoping some of you can help me out with the problem that I'm having
 as I'm not very good when it comes to networking..

 I've recently configured 6.3-PRERELEASE with IPFW/NATD to act as my
 LAN's firewall/router.  After I initially access certain http sites,
 particularly google groups and yahoo web mail I'm noticing subsequent
 attempts take  2mins to resolve the next link that I am interested in
 reading.

 This appears to be caused by rule 01000 as the counter increases each
 time I access one of the above mentioned sites.

 Short of removing this rule, is there any other way that I can fix this
 issue?  Below is a listing of my present ruleset and a tcpdump of a
 Windows XP machine trying to access a link on google groups.

 regards,

 Gardner

 mx1# ipfw show
 00100   76  11134 allow ip from 127.0.0.1 to 127.0.0.1 via lo0
 002000  0 deny log logamount 10 ip from 127.0.0.1 to any
 003000  0 deny log logamount 10 ip from any to 127.0.0.1
 004000  0 deny log logamount 10 ip from any to any not
 verrevpath in
 005000  0 deny log logamount 10 ip from any to any ipoptions
 ssrr,lsrr,rr,ts in
 006000  0 deny ip from any to any frag
 007000  0 allow icmp from any to any icmptypes 0,3,11,12
 00800 1081 452405 divert 8668 ip from any to any via bge0
 009000  0 check-state
 01000   36  17682 deny tcp from any to any established
 01100 2704 853904 allow ip from any to any via bge1 keep-state 01200
 262  57586 allow tcp from any to any dst-port 80 keep-state
 013000  0 allow tcp from any to any dst-port 443 keep-state
 01400  102   7752 allow udp from me to any dst-port 123 keep-state
 015000  0 allow tcp from me to any dst-port 53 setup keep-state
 01600  169  30563 allow udp from me to any dst-port 53 keep-state
 017000  0 allow tcp from any to any dst-port 1863 setup
 keep-state
 018000  0 allow log logamount 10 udp from any to
 255.255.255.255 dst-port 68 in via bge0
 019000  0 allow tcp from x.x.x.x to x.x.x.x dst-port 22
 keep-state
 020000  0 deny log logamount 10 ip from any to any
 655351396 deny ip from any to any

 131219 00:e0:81:2e:c1:aa  00:13:5f:04:bd:05, ethertype IPv4 (0x0800),
 length 54: (tos 0x0, ttl  63, id 55490, offset 0, flags  [DF], proto:
 TCP (6), length: 40, bad cksum 0 (-4d44)!) x.x.x.x.2471
 64.233.179.99.80: ., cksum 0x2bf0 (correct), a
 ck 26946 win 64330
 046227 00:e0:81:2e:c1:aa  00:13:5f:04:bd:05, ethertype IPv4 (0x0800),
 length 62: (tos 0x0, ttl  63, id 55493, offset 0, flags  [DF], proto:
 TCP (6), length: 48, bad cksum 0 (-2a14)!) x.x.x.x.2474
 72.14.207.99.80: S, cksum 0xf365 (correct), 22
 96693740:2296693740(0) win 65535 mss 1460,nop,nop,sackOK
 007127 00:13:5f:04:bd:05  00:e0:81:2e:c1:aa, ethertype IPv4 (0x0800),
 length 62: (tos 0x0, ttl  56, id 48846, offset 0, flags  [none], proto:
 TCP (6), length: 48) 72.14.207.99.80  x.x.x.x.2474: S, cksum 0x8043
 (correct), 2154814567:2154814567(0
 ) ack 2296693741 win 5720 mss 1430,nop,nop,sackOK
 000323 00:e0:81:2e:c1:aa  00:13:5f:04:bd:05, ethertype IPv4 (0x0800),
 length 54: (tos 0x0, ttl  63, id 55494, offset 0, flags  [DF], proto:
 TCP (6), length: 40, bad cksum 0 (-2a1b)!) x.x.x.x.2474
 72.14.207.99.80: ., cksum 0xc341 (correct), ac
 k 1 win 65535
 000293 00:e0:81:2e:c1:aa  00:13:5f:04:bd:05, ethertype IPv4 (0x0800),
 length 1155: (tos 0x0, ttl  63, id 55495, offset 0, fla gs [DF], proto:
 TCP (6), length: 1141, bad cksum 0 (-25cd)!)
 x.x.x.x.2474  72.14.207.99.80: P 1:1102(1101) ack 1 win
 65535
 015474 00:13:5f:04:bd:05  00:e0:81:2e:c1:aa, ethertype IPv4 (0x0800),
 length 60: (tos 0x0, ttl  56, id 48847, offset 0, flags  [none], proto:
 TCP (6), length: 40) 72.14.207.99.80  x.x.x.x.2474: ., cksum 0xa0d9
 (correct), ack 1102 win 7707
 000879 00:13:5f:04:bd:05  00:e0:81:2e:c1:aa, ethertype IPv4 (0x0800),
 length 383: (tos 0x0, ttl  56, id 48848, offset 0, flag s [none], proto:
 TCP (6), length: 369) 72.14.207.99.80  x.x.x.x.2474:
 P 1:330(329) ack 1102 win 7707
 003365 00:13:5f:04:bd:05  00:e0:81:2e:c1:aa, ethertype IPv4

Re: Policy Routing natd+ipfw

[Jason Hills]

On 5/5/07, Patrick Tracanelli [EMAIL PROTECTED] wrote:

 How can I do policy routing with ipfw+natd?

 I started 2 natd processes, using natd.conf and natd2.conf
 respectively, but things dont work. My rules are:

Long time ago, PHK added an (undocumented, except for commit logs) feature
in natd(8), called instances. To use it, you can start a config file
with the instance keyword followed with an identifier, and in a certain
moment use the instance keyword again, with a second identifier. Each
block will create different natd instances which can be used with
independent configurations. However they are run by the same proccess.

Here is an (production) example:


Very good, it worked fine. I am happy I can stop running 2 natds. It was ugly.



To do so in your enviroment, divert packets to the second link when they
reach the main outgoing interface (tradditional path the packet would
flow, according to routing table):

divert 8669 ip from $net2 to any out via $ext_if1

Yes, this WILL work. Packets will be diverted to second natd instance when
it reaches the main outgoing interface (as main, I want you to read: the
one used by default route).


It sounds like it worked. Packets hit the rule correctly, but I dont
go to Internet.



So, here you are forgetting another mandatory flow control: you have to
send packets from your second-link IP address to your second-link gateway.
IPFW´s fwd action will do this like a charm =)


I believe this is why I dont get to internet. I didnt understand this
ipfw fwd thing you mentioned. Could you give some example?




 divert 8668 ip from any to any via $ext_if1
 divert 8669 ip from any to any via $ext_if2

 My defaultrouter is the one on $ext_if1.

 It works for port 8668 but doesnt work for 8669 (the second xDSL link)

 --
 Jazzie Hills


--
Patrick Tracanelli
(31) 3281 9633
sip://[EMAIL PROTECTED]





--
Jazzie Hills
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]

Policy Routing natd+ipfw

[Jason Hills]

Hello.

How can I do policy routing with ipfw+natd?

I started 2 natd processes, using natd.conf and natd2.conf
respectively, but things dont work. My rules are:

ext_ifi1=em0
ext_ifi2=em1

divert 8668 ip from $net1 to any out via $ext_if1
divert 8669 ip from $net2 to any out via $ext_if2

divert 8668 ip from any to any via $ext_if1
divert 8669 ip from any to any via $ext_if2

My defaultrouter is the one on $ext_if1.

It works for port 8668 but doesnt work for 8669 (the second xDSL link)

--
Jazzie Hills
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]