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?

masegaloeh
  • 17,978
  • 9
  • 56
  • 104
Dave Knell
  • 21
  • 1
  • 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 '14 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 '14 at 23:22

1 Answers1

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
Pat
  • 3,339
  • 2
  • 16
  • 17
  • 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 '14 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 '14 at 17:29
  • they both work... – Pat Sep 26 '14 at 21:46
  • Any ideas on the other half of the puzzle - packets going from inside to outside? – Dave Knell Sep 26 '14 at 22:28
  • your puzzle is already solved, the NAT engine does the rest. – Pat Sep 26 '14 at 22:42
  • No; it does too much. What I need is direct port mapping from inside to outside and back again, and the NAT engine does more than just that. – Dave Knell Sep 28 '14 at 01:35
  • Please read your question. If you need a different thing then take the time for completely describe your problem and needs in a different question. At this point this thread is already solved. The incoming traffic is correctly routed and the outcoming traffic is also correctly routed – Pat Sep 28 '14 at 09:15
  • With all due respect, the question is clear that packets need to go through both ways with their ports unchanged. DNAT will do that for incoming traffic, but you've not addressed this point for outgoing traffic. – Dave Knell Sep 29 '14 at 13:11
  • see the edit; please consider all your IPs belong to the same network; I think this fact could bring problems... – Pat Sep 29 '14 at 13:54