(apologies if you see this twice; I accidentally sent as HTML first.) Add an /etc/hosts entry on cave that maps maar to 127.0.0.1? Not great if you want cave to get to maar and you don't have an alternate set of LAN addresses, I suppose. If cave is trying to access XMPP on itself, then would it also want to access HTTPS? If so, then bouncing traffic through maar seems like a good thing. For the direct answer you're looking for, though, are you saying the direct approach doesn't work?: iptables -t nat -A OUTPUT -p tcp -d maar --dport 443 -j DNAT --to-destination localhost:5222 If you have all these public IPs, can't you get more than one for cave and dispense with all of the NATting? On Mon, May 3, 2010 at 7:21 AM, Simon Tennant <simon@xxxxxxxxxxxxxx> wrote: > > On 03/05/2010 16:01, Jan Engelhardt wrote: >>> >>> My question is what DNAT or SNAT rules do we need to add to cave or to maar so >>> that remote *and local (originating from cave)* clients can make xmpp >>> connecitons on 443 and end up on cave:5222?\ >>> >> >> Since they have all public addresses, no NAT is needed. >> > > Just to clarify: both services run on one host. The second host (maar) doesn't host any services and shouldn't. It's role in this is just forwarding maar:443 -> cave:5222. Ordinarily I'd just have a listener for xmpp on cave:443 but that's taken by apache. Hence this packet wangling. > > S. > > -- > Simon Tennant > > +44 20 7043 6756 (UK - office) > +49 17 8545 0880 (Germany - mobile) > +49 89 4209 55854 (Germany - office) > skype: simontennant > xmpp: simon@xxxxxxxxxxxxxx > > -- > To unsubscribe from this list: send the line "unsubscribe netfilter" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
