[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