Re: ipfw nat and smaller wan mtu

2022-12-07 Thread John Hay
Hi,

Adding this patch does make it work for me. There might be better ways to
do it. I have tested with ping and ssh. In ping's case, ping reported:
frag needed and DF set (MTU 1392)

In ssh's case I could see with tcpdump that the "need to frag (mtu 1392)"
was sent back and the next packet's length was adjusted.

#
06:29:59.869677 IP (tos 0x48, ttl 64, id 0, offset 0, flags [DF], proto TCP
(6), length 1500)
10.10.1.3.64344 > 10.10.7.7.22: Flags [.], cksum 0xb64d (correct), seq
39:1487, ack 39, win 1027, options [nop,nop,TS val 260430893 ecr
926374970], length 1448
06:29:59.869954 IP (tos 0x0, ttl 63, id 62454, offset 0, flags [none],
proto ICMP (1), length 596)
10.10.2.2 > 10.10.1.3: ICMP 10.10.7.7 unreachable - need to frag (mtu
1392), length 576
IP (tos 0x48, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length
1500, bad cksum e081 (->19b7)!)
10.10.1.3.64344 > 10.10.7.7.22: Flags [.], seq 39:1487, ack 39, win
1027, options [nop,nop,TS val 260430893 ecr 926374970], length 1448
06:29:59.871301 IP (tos 0x48, ttl 64, id 0, offset 0, flags [DF], proto TCP
(6), length 1392)
10.10.1.3.64344 > 10.10.7.7.22: Flags [.], cksum 0x6841 (correct), seq
39:1379, ack 39, win 1027, options [nop,nop,TS val 260430893 ecr
926374970], length 1340
#

--- sys/netinet/libalias/alias.c.orig   2022-05-12 04:54:03.0 +
+++ sys/netinet/libalias/alias.c2022-12-08 05:42:25.12798 +
@@ -365,6 +365,19 @@
lnk = NULL;

if (lnk != NULL) {
+   /*
+   If the packet was locally generated, it will have a
+   loopback address as source, which will not be handled
+   correctly. For now use the destination address as source
+   address. The correct source address might be the the
+   interface address that the packet will be going out on.
+   */
+   if (IN_LOOPBACK(ntohl(pip->ip_src.s_addr)) &&
+   !IN_LOOPBACK(ntohl(pip->ip_dst.s_addr))) {
+   DifferentialChecksum(&pip->ip_sum,
+   &pip->ip_dst, &pip->ip_src, 2);
+   pip->ip_src = pip->ip_dst;
+   }
if (ip->ip_p == IPPROTO_UDP || ip->ip_p == IPPROTO_TCP) {
int accumulate, accumulate2;
struct in_addr original_address;

On Wed, 7 Dec 2022 at 16:33, John Hay  wrote:

> Hi,
>
> What would the proper ipfw rules be to make nat work and properly get the
> icmp too big packets back to a local host if the wan interface needs a
> smaller mtu?
>
> I'm using a FreeBSD machine as router/firewall, but its wan interface
> needs a smaller mtu (1392) than the default ethernet mtu. I have replicated
> this in a VM so I can test it. My simplified ipfw rules make it work for
> packets that are smaller than the wan mtu:
>
> #
> net.inet.ip.fw.one_pass=0
> net.inet.ip.fw.verbose=1
> #
> fwcmd="/sbin/ipfw -q"
> wan="vtnet0"
> lan="vtnet1"
> ${fwcmd} nat 123 config if ${wan} log
> ${fwcmd} add 1000 count log all from any to any
> ${fwcmd} add 5000 nat 123 ip4 from any to any via ${wan}
> ${fwcmd} add 6000 allow log all from any to any
> #
> The wan ip of the firewall is 10.10.2.2 and the ip address of the host (on
> the lan side) I'm testing from is 10.10.1.3. And I did a ping to 10.10.5.5,
> which is on the other side of the wan interface.
>
> This works for packets smaller than the wan mtu. But if the packet is
> larger than the wan mtu, the icmp too big is generated, but with 127.0.0.1
> as the source and the wan ip as the destination and then sent via lo0 and
> it looks like this in the ipfw log:
>
> Dec  7 13:24:59 rtr kernel: ipfw: 1000 Count ICMP:3.4 127.0.0.1 10.10.2.2
> out via lo0
>
> So I added a nat ipfw rule to catch that:
>
> ${fwcmd} add 5050 nat 123 ip4 from any to not 127.0.0.1 via lo0
>
> That helped partly because it was then able to recover the address of the
> host I was testing from and tried to send the packet out on the correct
> interface (vtnet1). Unfortunately it still had the source address of
> 127.0.0.1, which means it did not actually make it to the wire:
>
> ##
> Dec  7 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:8.0 10.10.1.3 10.10.5.5
> in via vtnet1
> Dec  7 14:17:31 rtr kernel: ipfw: 6000 Accept ICMP:8.0 10.10.1.3 10.10.5.5
> in via vtnet1
> Dec  7 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:8.0 10.10.1.3 10.10.5.5
> out via vtnet0
> Dec  7 14:17:31 rtr kernel: ipfw: 6000 Accept ICMP:8.0 10.10.2.2 10.10.5.5
> out via vtnet0
> Dec  7 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:3.4 127.0.0.1 10.10.2.2
> out via lo0
> Dec  7 14:17:31 rtr kernel: ipfw: 6000 Accept ICMP:3.4 127.0.0.1 10.10.2.2
> out via lo0
> Dec  7 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:3.4 127.0.0.1 10.10.2.2
> in via lo0
> Dec  7 14:17:31 rtr kernel: ipfw: 6000 Accept ICMP:3.4 127.0.0.1 10.10.1.3
> in via lo0
> Dec  7 14:17:31 rtr kernel: ipfw: 1000 Count 

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"


Re: ipfw NAT, igb and hardware checksums

2016-01-13 Thread Alexander V . Chernikov
13.01.2016, 22:56, "Karim Fodil-Lemelin" :
> Hi,
>
> I've hit a very interesting problem with ipfw-nat and local TCP traffic
> that has enough TCP options to hit a special case in m_megapullup().
> Here is the story:
>
> I am using the following NIC:
>
> igb0@pci0:4:0:0: class=0x02 card=0x8086 chip=0x150e8086
> rev=0x01 hdr=0x00
>
> And when I do ipfw nat to locally emitted packets I see packets not
> being processed in the igb driver for HW checksum. Now a quick search
> for m_pullup in the igb driver code will show that our igb driver
> expects a contiguous ethernet + ip header in igb_tx_ctx_setup(). Now the
> friendly m_megapullup() in alias.c doesn't reserve any space before the
> ip header for the ethernet header after its call to m_getcl like
> tcp_output.c (see m->m_data += max_linkhdr in tcp_output.c).
>
> So the call to M_PREPEND() in ether_output() is forced to prepend a new
> mbuf for the ethernet header, leading to a non contiguous ether + ip.
> This in turn leads to a failure to properly read the IP protocol in the
> igb driver and apply the proper HW checksum function. Particularly this
> call in igb_tcp_ctx_setup(): ip = (struct ip *)(mp->m_data + ehdrlen);
Thanks for the detailed explanation. Looks reasonable. I'll do several more 
tests on that and commit.
>
> It would be nice if some FBSD comitter could review and hopefully add
> this patch to FBSD.
>
> Thank you,
>
> Karim.
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-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 NAT, igb and hardware checksums

2016-01-13 Thread Adrian Chadd
This looks mostly sensible. hm!



-a


On 13 January 2016 at 11:55, Karim Fodil-Lemelin
 wrote:
> Hi,
>
> I've hit a very interesting problem with ipfw-nat and local TCP traffic that
> has enough TCP options to hit a special case in m_megapullup(). Here is the
> story:
>
> I am using the following NIC:
>
> igb0@pci0:4:0:0:class=0x02 card=0x8086 chip=0x150e8086
> rev=0x01 hdr=0x00
>
> And when I do ipfw nat to locally emitted packets I see packets not being
> processed in the igb driver for HW checksum. Now a quick search for m_pullup
> in the igb driver code will show that our igb driver expects a contiguous
> ethernet + ip header in igb_tx_ctx_setup(). Now the friendly m_megapullup()
> in alias.c doesn't reserve any space before the ip header for the ethernet
> header after its call to m_getcl like tcp_output.c (see m->m_data +=
> max_linkhdr in tcp_output.c).
>
> So the call to M_PREPEND() in ether_output() is forced to prepend a new mbuf
> for the ethernet header, leading to a non contiguous ether + ip. This in
> turn leads to a failure to properly read the IP protocol in the igb driver
> and apply the proper HW checksum function. Particularly this call in
> igb_tcp_ctx_setup(): ip = (struct ip *)(mp->m_data + ehdrlen);
>
> To reproduce the issue I simply create a NAT rule for an igb interface and
> initiate a TCP connection locally going out through that interface (it
> should go through NAT obviously) something like:
>
> ipfw nat 1 config igb0 reset
> ipfw add 10 nat 1 via igb0
>
>  Although you need to make sure you fill enough of the SYN packet to trigger
> the allocation of new memory in m_megapullup. You can do this by using
> enough TCP options so its filling up almost all of the 256 mbuf or make
> RESERVE something like 300 bytes in alias.c.
>
> The fix I propose is very simple and faster for all drivers, including the
> ones that do perform a check for ether + ip to be contiguous upon accessing
> the IP header. If the leading space is available it doesn't allocate any
> extra space (as it should for most cases) but if for some reason the mbuf
> used doesn't have 100 bytes (RESERVE in megapullup) of free space it will
> reserve some at the front too. If the leading space isn't necessary then it
> won't cause any harm.
>
>
> -Subproject commit cfe39807fe9b1a23c13f73aabde302046736fa1c
> +Subproject commit cfe39807fe9b1a23c13f73aabde302046736fa1c-dirty
> diff --git a/freebsd/sys/netinet/libalias/alias.c
> b/freebsd/sys/netinet/libalias/alias.c
> index 876e958..dc424a6 100644
> --- a/freebsd/sys/netinet/libalias/alias.c
> +++ b/freebsd/sys/netinet/libalias/alias.c
> @@ -1757,7 +1757,8 @@ m_megapullup(struct mbuf *m, int len) {
>  * writable and has some extra space for expansion.
>  * XXX: Constant 100bytes is completely empirical. */
>  #defineRESERVE 100
> -   if (m->m_next == NULL && M_WRITABLE(m) && M_TRAILINGSPACE(m) >= RESERVE)
> + if (m->m_next == NULL && M_WRITABLE(m) &&
> + M_TRAILINGSPACE(m) >= RESERVE && M_LEADINGSPACE(m) >=
> max_linkhdr)
> return (m);
>
> if (len <= MCLBYTES - RESERVE) {
> @@ -1779,6 +1780,7 @@ m_megapullup(struct mbuf *m, int len) {
> goto bad;
>
> m_move_pkthdr(mcl, m);
> + mcl->m_data += max_linkhdr;
> m_copydata(m, 0, len, mtod(mcl, caddr_t));
> mcl->m_len = mcl->m_pkthdr.len = len;
> m_freem(m);
>
> It would be nice if some FBSD comitter could review and hopefully add this
> patch to FBSD.
>
> Thank you,
>
> Karim.
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-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 NAT show problems

2013-07-20 Thread wishmaster


 --- Original message ---
From: "isp" 
Date: 20 July 2013, 18:12:07

 
> Hi! I have problems with displaing information about NAT states on
> FreeBSD 9.1.
> There is no information when I use `ipfw nat 1 show`
  
  I have the same issue on my router 9.1-STABLE FreeBSD 9.1-STABLE #1
___
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 nat drops icmp packets from localhost

2011-10-06 Thread Oleg Strizhak

Здравствуйте, Alexander V. Chernikov!

Вы писали 06.10.2011 15:16:


...
svn diff -c 223835 svn://svn.freebsd.org/base/stable/8> ~/r223835.diff
Can you try the patch attached (just to be sure) ?


sure, I can =) I'll try and then drop you a line about the results.


This is exact situation from this (and some related PRs) and this
revision definitely fixes it.


Sounds promising! Hope I've missed or neglected something, and that'd help.


Thanks for you help once more! Now all goes as it have to; obviously 
that's my fault on the previous run. I suppose, wrong kernel is the most 
probable cause of that -- I've upgrade the system at that time. Sorry 
for wasting your time =(


But now I wonder why this patch isn't in RELENG_8_2 branch already? As 
far as I can see it's in RELENG_8 only. The bug seems to be widely 
occured and easy to catch, especially when moving to ipfw nat from 
ipfw+natd.


WBR,
Oleg


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

!DSPAM:4e8d95cf907971471292836!


___
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 nat drops icmp packets from localhost

2011-10-06 Thread Oleg Strizhak

Здравствуйте, Alexander V. Chernikov!

Вы писали 06.10.2011 15:16:


On 06.10.2011 14:42, Oleg Strizhak wrote:

Hello, Andrey V. Elsukov!

You wrote on 06.10.2011 at 13:38:


On 06.10.2011 12:29, Oleg Strizhak wrote:

After an investigation I've found out a very strange situation
- it seems to me, that ipfw nat drops some (type 11?) icmp
reply packets, whose udp request packets it hasn't
rewritten/seen before, e.g:

So, I wonder whether someone else has seen the same case under
the similar circumstances? Isn't it a bug within ipfw nat
module and is there any work-around/patch for that? I've surely
googled, but in vain =( The only thing, that seems alike to my
problem, is http://www.freebsd.org/cgi/query-pr.cgi?pr=129093,
but the patch for 8 branch didn't cure anything =(


Can you describe how you did apply and test this patch?


in a usual way =) Unfortunately, copy-pasted from the mentioned
above page patch couldn't be applied w/ error:


svn diff -c 223835 svn://svn.freebsd.org/base/stable/8>  ~/r223835.diff
Can you try the patch attached (just to be sure) ?


sure, I can =) I'll try and then drop you a line about the results.


This is exact situation from this (and some related PRs) and this
revision definitely fixes it.


Sounds promising! Hope I've missed or neglected something, and that'd help.


Btw, what is the value of net.inet.ip.fw.one_pass sysctl ?


now it's 0. As far as I remember, I've raised one_pass to 1 -- without 
any effect on the packets filtering (in my case)



Are you sure that ipfw is the single enabled firewall on this machine
? Are you sure that system is using new kernel ?


Just 10 minutes ago I was quite sure in both cases, without any doubt..
Now, as the patch you've sent to me is char-to-char the same as mine...
I'll try once more.
Thanx for help and directions!

WBR,
Oleg


!DSPAM:4e8d8e75828882115423180!

___
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 nat drops icmp packets from localhost

2011-10-06 Thread Alexander V. Chernikov
On 06.10.2011 14:42, Oleg Strizhak wrote:
> Hello, Andrey V. Elsukov!
> 
> You wrote on 06.10.2011 at 13:38:
> 
>> On 06.10.2011 12:29, Oleg Strizhak wrote:
>>> After an investigation I've found out a very strange situation - it
>>> seems to me, that ipfw nat drops
>>> some (type 11?) icmp reply packets, whose udp request packets it
>>> hasn't rewritten/seen before, e.g:
>>>
>>> So, I wonder whether someone else has seen the same case under the
>>> similar circumstances? Isn't it a
>>> bug within ipfw nat module and is there any work-around/patch for
>>> that? I've surely googled, but in
>>> vain =( The only thing, that seems alike to my problem, is
>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=129093, but the patch for
>>> 8 branch didn't cure anything =(
>>
>> Can you describe how you did apply and test this patch?
> 
> in a usual way =) Unfortunately, copy-pasted from the mentioned above
> page patch couldn't be applied w/ error:

svn diff -c 223835 svn://svn.freebsd.org/base/stable/8 > ~/r223835.diff
Can you try the patch attached (just to be sure) ?

This is exact situation from this (and some related PRs) and this
revision definitely fixes it.

Btw, what is the value of net.inet.ip.fw.one_pass sysctl ?
Are you sure that ipfw is the single enabled firewall on this machine ?
Are you sure that system is using new kernel ?


> 
>> $ patch < ~/ip_fw_nat.patch
>> Hmm...  Looks like a unified diff to me...
>> The text leading up to this was:
>> --
>> |--- stable/8/sys/netinet/ipfw/ip_fw_nat.c  Thu Jul 7 08:33:58
>> 2011 (r223834)
>> |+++ stable/8/sys/netinet/ipfw/ip_fw_nat.c  Thu Jul 7 09:29:11
>> 2011 (r223835)
>> --
>> Patching file ip_fw_nat.c using Plan A...
>> patch:  malformed patch at line 4: else
> 
> the same results were obtained with combinations of -p5 -l and tail +2
> ~/ip_fw_nat.patch options & commands
> Finally, I modified the patch (which applies w/o a word =) a little bit
> w/o any difference to the original one:
> 
>>  $ /usr/bin/diff -wBbu3 ~/ip_fw_nat.patch ~/ip_fw_nat.patch.my
>> --- /root/ip_fw_nat.patch   2011-10-04 14:08:32.0 +0400
>> +++ /root/ip_fw_nat.patch.my2011-10-04 14:29:53.0 +0400
>> @@ -1,5 +1,5 @@
>>  stable/8/sys/netinet/ipfw/ip_fw_nat.c  Thu Jul 7 08:33:58
>> 2011 (r223834)
>> -+++ stable/8/sys/netinet/ipfw/ip_fw_nat.c  Thu Jul 7 09:29:11
>> 2011 (r223835)
>> +--- ip_fw_nat.c.orig   2010-12-21 20:09:25.0 +0300
>>  ip_fw_nat.c2011-10-04 14:27:02.0 +0400
>>  @@ -263,17 +263,27 @@
>>  else
>>  retval = LibAliasOut(t->lib, c,
> 
> then I recompiled the kernel, rebooted server and.. all is just the same =(
> 
> WBR,
> Oleg
> 

Index: sys/netinet/ipfw/ip_fw_nat.c
===
--- sys/netinet/ipfw/ip_fw_nat.c(revision 223834)
+++ sys/netinet/ipfw/ip_fw_nat.c(revision 223835)
@@ -263,17 +263,27 @@
else
retval = LibAliasOut(t->lib, c,
mcl->m_len + M_TRAILINGSPACE(mcl));
-   if (retval == PKT_ALIAS_RESPOND) {
-   m->m_flags |= M_SKIP_FIREWALL;
-   retval = PKT_ALIAS_OK;
-   }
-   if (retval != PKT_ALIAS_OK &&
-   retval != PKT_ALIAS_FOUND_HEADER_FRAGMENT) {
+
+   /*
+* We drop packet when:
+* 1. libalias returns PKT_ALIAS_ERROR;
+* 2. For incoming packets:
+*  a) for unresolved fragments;
+*  b) libalias returns PKT_ALIAS_IGNORED and
+*  PKT_ALIAS_DENY_INCOMING flag is set.
+*/
+   if (retval == PKT_ALIAS_ERROR ||
+   (args->oif == NULL && (retval == PKT_ALIAS_UNRESOLVED_FRAGMENT ||
+   (retval == PKT_ALIAS_IGNORED &&
+   (t->lib->packetAliasMode & PKT_ALIAS_DENY_INCOMING) != 0 {
/* XXX - should i add some logging? */
m_free(mcl);
args->m = NULL;
return (IP_FW_DENY);
}
+
+   if (retval == PKT_ALIAS_RESPOND)
+   m->m_flags |= M_SKIP_FIREWALL;
mcl->m_pkthdr.len = mcl->m_len = ntohs(ip->ip_len);
 
/*

Property changes on: sys/contrib/pf
___
Modified: svn:mergeinfo
   Merged /head/sys/contrib/pf:r222806


Property changes on: sys/contrib/dev/acpica
___
Modified: svn:mergeinfo
   Merged /head/sys/contrib/dev/acpica:r222806


Property changes on: sys/cddl/contrib/opensolaris
___
Modified: svn:mergeinfo
   Merged /head/sys/cddl/contrib/opensolaris:r222806


Property changes on: sys/amd64/include/xen
___
Modified: svn:mergeinfo
   Merged /head/sys/amd64/include/xen:r222806


Property changes on: sys
___

Re: ipfw nat drops icmp packets from localhost [patch attached]

2011-10-06 Thread Oleg Strizhak

Здравствуйте, Andrey V. Elsukov!

Вы писали 06.10.2011 13:38:


On 06.10.2011 12:29, Oleg Strizhak wrote:

After an investigation I've found out a very strange situation - it seems to 
me, that ipfw nat drops
some (type 11?) icmp reply packets, whose udp request packets it hasn't 
rewritten/seen before, e.g:

So, I wonder whether someone else has seen the same case under the similar 
circumstances? Isn't it a
bug within ipfw nat module and is there any work-around/patch for that? I've 
surely googled, but in
vain =( The only thing, that seems alike to my problem, is
http://www.freebsd.org/cgi/query-pr.cgi?pr=129093, but the patch for 8 branch 
didn't cure anything =(


Can you describe how you did apply and test this patch?


I beg your pardon: in my previous reply I forgot to attach my patch. 
Here it is


WBR,
Oleg
--- ip_fw_nat.c.orig2010-12-21 20:09:25.0 +0300
+++ ip_fw_nat.c 2011-10-04 14:27:02.0 +0400
@@ -263,17 +263,27 @@
else
retval = LibAliasOut(t->lib, c,
mcl->m_len + M_TRAILINGSPACE(mcl));
-   if (retval == PKT_ALIAS_RESPOND) {
-   m->m_flags |= M_SKIP_FIREWALL;
-   retval = PKT_ALIAS_OK;
-   }
-   if (retval != PKT_ALIAS_OK &&
-   retval != PKT_ALIAS_FOUND_HEADER_FRAGMENT) {
+
+   /*
+* We drop packet when:
+* 1. libalias returns PKT_ALIAS_ERROR;
+* 2. For incoming packets:
+*  a) for unresolved fragments;
+*  b) libalias returns PKT_ALIAS_IGNORED and
+*   PKT_ALIAS_DENY_INCOMING flag is set.
+*/
+   if (retval == PKT_ALIAS_ERROR ||
+(args->oif == NULL && (retval == PKT_ALIAS_UNRESOLVED_FRAGMENT ||
+(retval == PKT_ALIAS_IGNORED &&
+(t->lib->packetAliasMode & PKT_ALIAS_DENY_INCOMING) != 0 {
/* XXX - should i add some logging? */
m_free(mcl);
args->m = NULL;
return (IP_FW_DENY);
}
+
+   if (retval == PKT_ALIAS_RESPOND)
+m->m_flags |= M_SKIP_FIREWALL;
mcl->m_pkthdr.len = mcl->m_len = ntohs(ip->ip_len);
 
/*
___
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 nat drops icmp packets from localhost

2011-10-06 Thread Oleg Strizhak

Hello, Andrey V. Elsukov!

You wrote on 06.10.2011 at 13:38:


On 06.10.2011 12:29, Oleg Strizhak wrote:

After an investigation I've found out a very strange situation - it seems to 
me, that ipfw nat drops
some (type 11?) icmp reply packets, whose udp request packets it hasn't 
rewritten/seen before, e.g:

So, I wonder whether someone else has seen the same case under the similar 
circumstances? Isn't it a
bug within ipfw nat module and is there any work-around/patch for that? I've 
surely googled, but in
vain =( The only thing, that seems alike to my problem, is
http://www.freebsd.org/cgi/query-pr.cgi?pr=129093, but the patch for 8 branch 
didn't cure anything =(


Can you describe how you did apply and test this patch?


in a usual way =) Unfortunately, copy-pasted from the mentioned above 
page patch couldn't be applied w/ error:



$ patch < ~/ip_fw_nat.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|--- stable/8/sys/netinet/ipfw/ip_fw_nat.c  Thu Jul 7 08:33:58 2011 
(r223834)
|+++ stable/8/sys/netinet/ipfw/ip_fw_nat.c  Thu Jul 7 09:29:11 2011 
(r223835)
--
Patching file ip_fw_nat.c using Plan A...
patch:  malformed patch at line 4: else


the same results were obtained with combinations of -p5 -l and tail +2 
~/ip_fw_nat.patch options & commands
Finally, I modified the patch (which applies w/o a word =) a little bit 
w/o any difference to the original one:



 $ /usr/bin/diff -wBbu3 ~/ip_fw_nat.patch ~/ip_fw_nat.patch.my
--- /root/ip_fw_nat.patch   2011-10-04 14:08:32.0 +0400
+++ /root/ip_fw_nat.patch.my2011-10-04 14:29:53.0 +0400
@@ -1,5 +1,5 @@
 stable/8/sys/netinet/ipfw/ip_fw_nat.c  Thu Jul 7 08:33:58 2011 
(r223834)
-+++ stable/8/sys/netinet/ipfw/ip_fw_nat.c  Thu Jul 7 09:29:11 2011 
(r223835)
+--- ip_fw_nat.c.orig   2010-12-21 20:09:25.0 +0300
 ip_fw_nat.c2011-10-04 14:27:02.0 +0400
 @@ -263,17 +263,27 @@
 else
 retval = LibAliasOut(t->lib, c,


then I recompiled the kernel, rebooted server and.. all is just the same =(

WBR,
Oleg
___
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 nat drops icmp packets from localhost

2011-10-06 Thread Andrey V. Elsukov
On 06.10.2011 12:29, Oleg Strizhak wrote:
> After an investigation I've found out a very strange situation - it seems to 
> me, that ipfw nat drops
> some (type 11?) icmp reply packets, whose udp request packets it hasn't 
> rewritten/seen before, e.g:
> 
> So, I wonder whether someone else has seen the same case under the similar 
> circumstances? Isn't it a
> bug within ipfw nat module and is there any work-around/patch for that? I've 
> surely googled, but in
> vain =( The only thing, that seems alike to my problem, is
> http://www.freebsd.org/cgi/query-pr.cgi?pr=129093, but the patch for 8 branch 
> didn't cure anything =(

Can you describe how you did apply and test this patch?

-- 
WBR, Andrey V. Elsukov
___
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 - NAT - two gateway -HELP

2011-01-01 Thread Julian Elischer

On 1/1/11 10:42 PM, Nima Khoramdin wrote:

hello again

ok Maybe I was wrong explain. I already have an ip address in my network is
working with NAT ( nat to internal web server )  , i want to add another NIC
with a new isp (IP) for backup, and new nat rule.

how can i set two separated  gateways on freebsd.

thanx


so, your addresses are NOT 172... and 10.?

Assuming you have a way to get the externally sourced packets to your
interface, then you have a couple of options.
Firstly you will need to either use two natd instances, or single
natd using tow of the new 'instance' sections.

(quoting from the natd man page...)
   start quote---
 Options can be divided to several sections.  Each 
section
 applies to own natd instance.  This ability allows 
to config-
 ure one natd process for several NAT instances.  The 
first
 instance that always exists is a "default" 
instance.  Each

 another instance should begin with

   instance instance_name

 At the next should be placed a configuration 
option.  Exam-

 ple:

   # default instance
   port 8668
   alias_address 158.152.17.1

   # second instance
   instance dsl1
   port 
   alias_address 192.168.0.1

 Trailing spaces and empty lines are ignored.  A `#' 
sign will

 mark the rest of the line as a comment.

 -instance instancename
 This option switches command line options processing 
to con-
 figure instance instancename (creating it if 
necessary) till
 the next -instance option or end of command line.  
It is eas-
 ier to set up multiple instances in the 
configuration file
 specified with the -config option rather than on a 
command

 line.
   - end quote-

you can then use the ipfw 'fwd' command to decide which goes where
or alternatively, you can also use the new multiple routing table feature
to decide which sessions go to which gateway.



ISP1  ISP2
wireless connection   ADSL
2mb/2mb 1mb/1mb
172.16.1.1/23   10.0.0.1/23

  | |
  | |
  | |
  | |
 static   static
  172.16.1.510.0.1.15
*aue0***tun0*
*  FreeBSD *
*ep0*

 192.168.1.254
 |
 |
   *
Private LAN
  192.168.1.0/24
  |
  |
  |
  webserver

192.168.1.121


how to use of this two gateways for my internal webserver with ipfw&   nat

i want to know how can i use ISP2 adsl as ISP1 ( i mean if anyone put ISP1
(172.16.1.5) , ISP2 (10.0.10.15) to the browser , can see my internal
webserver page with two  separated ISPs ) not load balance . i want to use
two ISPs at the same time .


do you REALLY have 172.16.1.5 and 10.0.1.15 as your IP addresses?
If so there is no way you can be reached from the outside..
unless you have made an agreement with the ISPs to forward some address/port
to you.
They are doing NAT on your outgoing sessions as it is already..




  sorry for my bad explanation

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



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



___
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 - NAT - two gateway -HELP

2011-01-01 Thread Julian Elischer

On 1/1/11 5:11 AM, Nima Khoramdin wrote:

hello .

I installed freebsd 7.1 with ifpw - nat - dummynet with below kernel config
:

options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=100
options IPFIREWALL_FORWARD
options IPDIVERT
options DUMMYNET
options HZ=1000


and i have three NICs , with internal webserver works with nat:

default gw : 172.16.1.5

(in natd.conf :

port 8668
interface nfe0
use_sockets yes

# redirect to webserver
redirect_port tcp 192.168.1.121:80 172.16.1.5:80)
webserver
)

it works fine.


ISP1  ISP2
wireless connection   ADSL
2mb/2mb 1mb/1mb
172.16.1.1/23   10.0.0.1/23

  | |   
  | |   
  | |   
  | |   
 static   static
  172.16.1.510.0.1.15
*aue0***tun0*
*  FreeBSD *
*ep0*   

 192.168.1.254
 |  
 |  
   *
Private LAN
  192.168.1.0/24
  |
  |
  |
  webserver

192.168.1.121


how to use of this two gateways for my internal webserver with ipfw&  nat

i want to know how can i use ISP2 adsl as ISP1 ( i mean if anyone put ISP1
(172.16.1.5) , ISP2 (10.0.10.15) to the browser , can see my internal
webserver page with two  separated ISPs ) not load balance . i want to use
two ISPs at the same time .

do you REALLY have 172.16.1.5 and 10.0.1.15 as your IP addresses?
If so there is no way you can be reached from the outside..
unless you have made an agreement with the ISPs to forward some 
address/port to you.

They are doing NAT on your outgoing sessions as it is already..





sorry for my bad explanation
thanx
___
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"



___
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 nat and localy initiated UDP traffic (bad udp cksum)

2009-07-16 Thread Chuck Swiger

On Jul 16, 2009, at 12:19 PM, Dmitriy Demidov wrote:

Update about this issue.
There is somthing wrong with UDP pass through - ipfw nat makes it  
"bad cksum".


tcpdump receives local network traffic before the checksums are  
computed (especially if hardware checksums are enabled); this is a non- 
issue, although you could confirm by sniffing the traffic from an  
external machine like a laptop.


Regards,
--
-Chuck

___
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 nat and localy initiated UDP traffic (bad udp cksum)

2009-07-16 Thread Dmitriy Demidov
On Thursday 16 July 2009, Chuck Swiger wrote:
> On Jul 16, 2009, at 12:19 PM, Dmitriy Demidov wrote:
> > Update about this issue.
> > There is somthing wrong with UDP pass through - ipfw nat makes it
> > "bad cksum".
>
> tcpdump receives local network traffic before the checksums are
> computed (especially if hardware checksums are enabled); this is a non-
> issue, although you could confirm by sniffing the traffic from an
> external machine like a laptop.
>
> Regards,

Wow! :) Thank you Chuck for this hint! I catch the problem!
My em0 have offload options on, so I turned them off and now all is working as 
expected.


before:
===
em0: flags=8843 metric 0 mtu 1500
options=9b
ether 00:20:ed:91:97:93
inet 87.110.108.74 netmask 0xfe00 broadcast 255.255.255.255
media: Ethernet autoselect (100baseTX )
status: active
===


after:
===
em0: flags=8843 metric 0 mtu 1500
options=98
ether 00:20:ed:91:97:93
inet 87.110.108.74 netmask 0xfe00 broadcast 255.255.255.255
media: Ethernet autoselect (100baseTX )
status: active
===


dmesg | grep em0
===
em0:  port 0xa000-0xa03f mem 
0xdb10-0xdb11 irq 21 at device 9.0 on pci2
em0: [FILTER]
em0: Ethernet address: 00:20:ed:91:97:93
===


pciconf -lv
===
e...@pci0:2:9:0: class=0x02 card=0x30138086 chip=0x100e8086 rev=0x02 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Gigabit Ethernet Controller (82540EM)'
class  = network
subclass   = ethernet
===



Do this looks like a bug (em drivers, nat, etc...) or not?
Should I make new PR for this problem?

___
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 nat and localy initiated UDP traffic (bad udp cksum)

2009-07-16 Thread Dmitriy Demidov
On Tuesday 14 July 2009, Dmitriy Demidov wrote:
> Hi list.
>
> I have a problems with ipfw nat. It makes me crazy (I realy have no idea
> how to troubleshoot this problem). Looks like ipfw nat do not pass through
> itself localy initiated UDP traffic! Is there any hint that I do not know
> about ipfw nat? Any clue please :(
>

Update about this issue.
There is somthing wrong with UDP pass through - ipfw nat makes it "bad cksum".



tcpdump on ISP-side nic (tcpdump -i 2 -X -vvv -n -l ip) shows this:

for localy initiated UDP/DNS trafic:

21:58:30.116680 IP (tos 0x0, ttl 64, id 6212, offset 0, flags [none], proto 
UDP (17), length 61) 87.110.108.74.62365 > 91.198.156.20.53: [bad udp cksum 
aa89!] 50277+ A? www.freebsd.org. (33)
0x:  4500 003d 1844  4011 a6d9 576e 6c4a  e..=@...wnlj
0x0010:  5bc6 9c14 f39d 0035 0029 bbcd c465 0100  [..5.)...e..
0x0020:  0001    0377  0766 7265  .www.fre
0x0030:  6562 7364 036f 7267  0100 01 ebsd.org.
21:58:35.116809 IP (tos 0x0, ttl 64, id 6239, offset 0, flags [none], proto 
UDP (17), length 61) 87.110.108.74.62365 > 91.198.156.20.53: [bad udp cksum 
aa89!] 50277+ A? www.freebsd.org. (33)
0x:  4500 003d 185f  4011 a6be 576e 6c4a  e..=@...wnlj
0x0010:  5bc6 9c14 f39d 0035 0029 bbcd c465 0100  [..5.)...e..
0x0020:  0001    0377  0766 7265  .www.fre
0x0030:  6562 7364 036f 7267  0100 01 ebsd.org.
21:58:40.117744 IP (tos 0x0, ttl 64, id 6240, offset 0, flags [none], proto 
UDP (17), length 61) 87.110.108.74.62365 > 91.198.156.20.53: [bad udp cksum



for UDP/DNS trafic that pass via nat from local network:

21:58:21.925741 IP (tos 0x0, ttl 63, id 632, offset 0, flags [none], proto UDP 
(17), length 61) 87.110.108.74.58124 > 91.198.156.20.53: [udp sum ok] 36465+ 
A? www.freebsd.org. (33)
0x:  4500 003d 0278  3f11 bda5 576e 6c4a  E..=.x..?...WnlJ
0x0010:  5bc6 9c14 e30c 0035 0029 8bfd 8e71 0100  [..5.)...q..
0x0020:  0001    0377  0766 7265  .www.fre
0x0030:  6562 7364 036f 7267  0100 01 ebsd.org.
21:58:21.932623 IP (tos 0x0, ttl 59, id 39585, offset 0, flags [none], proto 
UDP (17), length 165) 91.198.156.20.53 > 87.110.108.74.58124: 36465 q: A? 
www.freebsd.org. 1/3/0 www.freebsd.org. A 69.147.83.33 ns: freebsd.org.[|
domain]
0x:  4500 00a5 9aa1  3b11 2914 5bc6 9c14  E...;.).[...
0x0010:  576e 6c4a 0035 e30c 0091 8f66 8e71 8180  WnlJ.5.f.q..
0x0020:  0001 0001 0003  0377  0766 7265  .www.fre
0x0030:  6562 7364 036f 7267  0100 01c0 0c00  ebsd.org
0x0040:  0100 0100 000b 6600 0445 9353 21c0 1000  ..f..E.S!...
0x0050:  0200 ..


ipfw config:

add allow ip from any to any via fxp0
add allow udp from any 68 to any 67
add allow udp from any 67 to any 68
add count ip from any to any
nat 1 config log if em0 reset same_ports deny_in
nat 2 config log if em0
nat 3 config log if em0 reset same_ports deny_in
add count ip from any to any
add nat 1 tcp from any to any out xmit em0
add nat 2 udp from any to any out xmit em0
add nat 3 icmp from any to any out xmit em0
add nat 1 tcp from any to me in recv em0
add nat 2 udp from any to me in recv em0
add nat 3 icmp from any to me in recv em0
add count ip from any to any


ipfw show

00100 1642 372640 allow ip from any to any via lo0
002000  0 deny ip from any to 127.0.0.0/8
003000  0 deny ip from 127.0.0.0/8 to any
004009990 allow ip from any to any via fxp0
005000  0 allow udp from any 68 to any dst-port 67
006000  0 allow udp from any 67 to any dst-port 68
00700   25   1404 count ip from any to any
00800   25   1404 count ip from any to any
009000  0 nat 1 tcp from any to any out xmit em0
010007427 nat 2 udp from any to any out xmit em0
011000  0 nat 3 icmp from any to any out xmit em0
01200   17812 nat 1 tcp from any to me in recv em0
013001165 nat 2 udp from any to me in recv em0
014000  0 nat 3 icmp from any to me in recv em0
015000  0 count ip from any to any
655353520 deny ip from any to any


uname -a
FreeBSD hius.local.home 7.2-STABLE FreeBSD 7.2-STABLE #0: Wed Jul 15 20:59:17 
EEST 2009 r...@hius.local.home:/usr/obj/usr/src/sys/STABLE  i386
___
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 + nat

2006-06-08 Thread Nick Withers
On Wed, 7 Jun 2006 20:17:07 -0300
"mufalani" <[EMAIL PROTECTED]> wrote:

> Hi all,
> 
> I have a webserver runing apache 2.3 under windows 2003, and one BSD 5.4 
> (gateway). 
> 
> How to redirect requisitions at 80´s port (200.X.X.X:80) to address 
> (192.x.x.x:80) with nat and ipfw?

Assuming you're running both already, simply adding the
following line (with the appropriate IP addresses, of course) to
your natd configuration should do the trick:

redirect_port tcp 192.x.x.x:80 200.X.X.X:80

Otherwise, I'd recommend reading the FreeBSD Handbook sections
on this
(http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html
and
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-natd.html,
for instance).

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

This probably belongs on freebsd-questions, by the way...
-- 
Nick Withers
email: [EMAIL PROTECTED]
Web: http://www.nickwithers.com
Mobile: +61 414 397 446
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: ipfw + nat

2006-06-08 Thread Erik
> Hi all,
>
> I have a webserver runing apache 2.3 under windows 2003, and one BSD 5.4 
> (gateway).
>
> How to redirect requisitions at 80´s port (200.X.X.X:80) to address 
> (192.x.x.x:80) with nat and ipfw?
>
Pretty simple if you are using natd.

In /etc/rc.conf:

### Firewall Settings ###
firewall_enable="YES"
ipdivert_enable="YES"
gateway_enable="YES"
firewall_type="MYOWN"
natd_enable="YES"
natd_interface="xl0"  (replace with your external interface)
natd_flags="-f /etc/rc.natd"
#

In /etc/rc.natd:

#
# NATD configurationfile that supplies NATD whit parameters
#

log no
use_sockets yes
same_ports yes

# Ports redirected to the internal network

redirect_port tcp 192.168.0.100:22 222
redirect_port tcp 192.168.0.111:80 80

^ redirecting  ^ obvious^ external port
^ type of traffic^ internal port

In the /etc/rc.firewall:

divert 8668 ip from any to any via xl0 (will be your external interface)



This is all there is to it (put in a simple way...)

Regards
/Erik


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

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


Re: ipfw + nat

2006-06-08 Thread Henrik Andersen

Hi Mufalani,
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html
and in particular the part 26.6.5.7 should explain how to accomplish this.

Regards,
Henrik

On 6/8/06, mufalani <[EMAIL PROTECTED]> wrote:

Hi all,

I have a webserver runing apache 2.3 under windows 2003, and one BSD 5.4 
(gateway).

How to redirect requisitions at 80´s port (200.X.X.X:80) to address 
(192.x.x.x:80) with nat and ipfw?


Att,
Rodrigo Mufalani

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


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


Re: ipfw + nat

2006-06-08 Thread Andrey V. Elsukov

mufalani wrote:
How to redirect requisitions at 80?s port (200.X.X.X:80) 

> to address (192.x.x.x:80) with nat and ipfw?

You can try following:
# natd -alias_address 200.X.X.X -redirect_port tcp 192.x.x.x:80 80
# ipfw add divert natd tcp from any to 200.X.X.X in recv $ExtIf
# ipfw add divert natd tcp from 192.x.x.x 80 to any out xmit $ExtIf

$ExtIf - external interface.

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


Re: ipfw + nat

2006-06-08 Thread Chuck Swiger

mufalani wrote:

Hi all,

I have a webserver runing apache 2.3 under windows 2003, and one BSD 5.4 (gateway). 


How to redirect requisitions at 80´s port (200.X.X.X:80) to address 
(192.x.x.x:80) with nat and ipfw?


echo "redirect_port tcp 192.x.x.x:80 80" >> /etc/natd.conf

See "man natd" for details and variants like redirect_address.

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