[OpenIndiana-discuss] IPNAT redirection.

DormitionSkete@hotmail.com dormitionskete at hotmail.com
Thu Apr 18 20:34:40 UTC 2013


On Apr 18, 2013, at 2:15 PM, Jonathan Adams wrote:

> In the past I have used "delegate" to do port forwarding on our internal
> servers, forwarding from a server directly connected to the internet, to
> one that has no direct connection.
> 
> I was about to set up delegate to do the same job, when it struck me that I
> should be able to use ipfilter, via ipnat to redirect the ports.
> 
> I have had success in the past with ipnat on another server, using "map" to
> send connections for https, and "rdr" to redirect to a proxy server running
> on the same machine.
> 
> I came to set up forwarding and although it says it's working, no packets
> are being forwarded internally.
> 
> my ipnat.conf
> rdr iprb0 any port 143 -> 192.168.0.12 port 143 tcp
> rdr bge0 any port 143 -> 192.168.0.12 port 143 tcp
> 
> If I try connecting using "telnet" the client stays "trying", and the
> "ipnat -l" shows that a connection is established, but if I snoop from
> 192.168.0.12 there are no packets coming in.
> 
> I'm sure I'm just missing 1 tiny detail.
> 
> Can anyone see what I'm missing, or point me in the correct direction?
> 
> Jon
> 
> root at fluffy:/etc/ipf# ipnat -vC -f /etc/ipf/ipnat.conf
> 4 entries flushed from NAT list
> rdr iprb0,bge0  0.0.0.0/0 port 143 -> 192.168.0.12 port 143 tcp
> 
> root at oldfluffy:/etc/ipf# ipadm show-if
> IFNAME     STATE    CURRENT      PERSISTENT
> lo0        ok       -m-v------46 ---
> bge0       ok       bm--------46 -46
> iprb0      ok       bm--------46 -46
> 
> root at oldfluffy:/etc/ipf# ipadm show-addr
> ADDROBJ           TYPE     STATE        ADDR
> lo0/v4            static   ok           127.0.0.1/8
> bge0/v4           static   ok           192.168.0.65/24
> iprb0/v4          static   ok           <external address>/28
> lo0/v6            static   ok           ::1/128
> 
> root at oldfluffy:/etc/ipf# ipadm show-ifprop bge0
> IFNAME      PROPERTY        PROTO PERM CURRENT    PERSISTENT DEFAULT
> POSSIBLE
> bge0        arp             ipv4  rw   on         --         on
> on,off
> bge0        forwarding      ipv4  rw   on         on         off
> on,off
> bge0        metric          ipv4  rw   0          --         0          --
> bge0        mtu             ipv4  rw   1500       --         1500
> 68-1500
> bge0        exchange_routes ipv4  rw   off        off        on
> on,off
> bge0        usesrc          ipv4  rw   none       --         none       --
> bge0        forwarding      ipv6  rw   off        --         off
> on,off
> bge0        metric          ipv6  rw   0          --         0          --
> bge0        mtu             ipv6  rw   1500       --         1500
> 1280-1500
> bge0        nud             ipv6  rw   on         --         on
> on,off
> bge0        exchange_routes ipv6  rw   on         --         on
> on,off
> bge0        usesrc          ipv6  rw   none       --         none       --
> 
> root at oldfluffy:/etc/ipf# ipadm show-ifprop iprb0
> IFNAME      PROPERTY        PROTO PERM CURRENT    PERSISTENT DEFAULT
> POSSIBLE
> iprb0       arp             ipv4  rw   on         --         on
> on,off
> iprb0       forwarding      ipv4  rw   on         on         off
> on,off
> iprb0       metric          ipv4  rw   0          --         0          --
> iprb0       mtu             ipv4  rw   1500       --         1500
> 68-1500
> iprb0       exchange_routes ipv4  rw   off        off        on
> on,off
> iprb0       usesrc          ipv4  rw   none       --         none       --
> iprb0       forwarding      ipv6  rw   off        --         off
> on,off
> iprb0       metric          ipv6  rw   0          --         0          --
> iprb0       mtu             ipv6  rw   1500       --         1500
> 1280-1500
> iprb0       nud             ipv6  rw   on         --         on
> on,off
> iprb0       exchange_routes ipv6  rw   on         --         on
> on,off
> iprb0       usesrc          ipv6  rw   none       --         none       --
> 
> root at oldfluffy:/etc/ipf# routeadm
>              Configuration   Current              Current
>                     Option   Configuration        System State
> ---------------------------------------------------------------
>               IPv4 routing   disabled             disabled
>               IPv6 routing   disabled             disabled
>            IPv4 forwarding   enabled              enabled
>            IPv6 forwarding   disabled             disabled
> 
>           Routing services   "route:default ripng:default"
> 
> Routing daemons:
> 
>                      STATE   FMRI
>                   disabled   svc:/network/routing/ripng:default
>                   disabled   svc:/network/routing/legacy-routing:ipv4
>                   disabled   svc:/network/routing/legacy-routing:ipv6
>                     online   svc:/network/routing/ndp:default
>                   disabled   svc:/network/routing/rdisc:default
>                   disabled   svc:/network/routing/route:default
> _______________________________________________
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss at openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
> 



From what I understand, you cannot use rdr within the same network segment -- ie. it looks like you're trying to redirect from 192.168.0.65 to 192.168.0.12 -- and apparently, that is *reflection*, not *redirection*.  You'd have to go from something like 192.168.0.65 to 192.168.1.12.

From:  http://www.symantec.com/connect/articles/solaris-and-ip-filter-how-to-make-them-your-nat-solution
But no longer accessible.


Disadvantages of Using IP Filter For NAT

IP Filter is very feature rich, which can be good and bad. It is good because there are so many things that users can do with IP Filter, depending on what their security goal is and how their choose to configure their firewall. The downside is that IP Filter can be configured in such a way that it may not work exactly as users expect. The key to solving this issue is to test everything - not just the new rule that has just been added, but all the rules in conjunction with this new rule as well.

Rule behavior can be unpredictable. When a new rule is thrown in the mix it may turn off something that the user did not intend to turn off. For instance, say that an administrator is trying to redirect traffic for a certain service to another server. If this server is on the same network segment, then the admin has effectively set up a reflector rather than an address redirection rule, which won't work anyway. Consider the following:

rdr nei0 150.50.52.3/24 port 21 ->  150.50.52.5/24 port 21
If the packet tries to go out of the same interface that it comes in on, the system will get confused.

Another situation in which it is easy to misconfigure the NAT gateway is when a user adds a rule that may already exist in some fashion in the active mappings. If the already-active mappings are not flushed out(using ipnat -F), then the rule might be useless. Good use of procedure in this case will alleviate any confusion.

If possible, users should set up a test environment in which to test rulesets prior to implementation. If this is not possible, then the ipnat does have a "-v" option, which turns on verbose so that users can see more information about how the rules are behaving.


HTH

If anyone knows how to do it within the same network segment, that would be a big help for me, too...






More information about the OpenIndiana-discuss mailing list