2

I'm looking to set up the following:

                              ---[IVR 1]
                             |
(internet)----[CentOS box]---+---[IVR 2]
                             |
                              ---[IVR 3]

The CentOS box's internal interface is 192.168.110.1, and the IVRs' 192.168.110.101-103.

What I'm trying to do is to map a bunch of external UDP ports across to each IVR - so, for example, ports 10000-14999 are mapped to IVR 1, 15000-19999 to IVR 2, etc. The problem I have is that the ports must be mapped directly across - i.e. something coming in from the internet to port 10000 will be sent to port 10000 on IVR, and something coming being sent from port 10000 in IVR 1 will be sent out from port 10000 on the internet-facing interface of the CentOS box.

iptables' NAT stuff all comes with the caveat that it'll try not to remap ports, but may have to.

Right now, my options look like:

  • map ports individually (15,000 iptables lines, one for each port) of the form ipables -t nat -A PREROUTING -i eth0 -p udp --dport 10000 -j DNAT --to 192.168.110.101:10000

  • build a kernel with the UDP conntrack timeouts turned right down

neither of which are terribly appealing.

What have I missed?

2
  • Are you sure you can't get real public IP addresses? Could you solve this with a VPN and skip trying to do address translation?
    – Zoredache
    Sep 25, 2014 at 17:01
  • We could use more public IP addresses - indeed, that's what we've been doing - but we've hit a limit. A VPN might work if we owned everything that the IVRs talk to, but we don't.
    – Dave Knell
    Sep 25, 2014 at 23:22

1 Answer 1

1

how about

PREROUTING -i eth0 -p udp --match multiport --dport 10000-14999 -j DNAT --to 192.168.110.101

or

PREROUTING -i eth0 -p udp --match multiport --dport 10000-14999 -j DNAT --to 192.168.110.101:10000-14999

edit

-t nat -A PREROUTING -i eth0 -p udp --match multiport --dport 10000-14999 -j DNAT --to 192.168.110.101
-t nat -A POSTROUTING -s 192.168.110.101 -j SNAT --to-destination 192.168.110.1
9
  • That might be one part of the solution; the other part is ensuring that packets get out without having their source ports changed. I suspect that's more likely to be where things are going wrong.
    – Dave Knell
    Sep 26, 2014 at 17:27
  • Indeed, the DNAT docs say that "If no port range is specified, then the destination port will never be modified.", so your first suggestion would work fine for packets from outside->inside.
    – Dave Knell
    Sep 26, 2014 at 17:29
  • they both work...
    – Pat
    Sep 26, 2014 at 21:46
  • Any ideas on the other half of the puzzle - packets going from inside to outside?
    – Dave Knell
    Sep 26, 2014 at 22:28
  • your puzzle is already solved, the NAT engine does the rest.
    – Pat
    Sep 26, 2014 at 22:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .