Change source IP at outgoing packet send by Bind9 as forwarder.

[CpServiceSPb .]

May be I posted my question too complicated.
So, let' s try with examples.

As I wrote I have Asterisk as well at the server binded only to internal IP
with external trunks that is it connects time to time to external VoIP
provider, that is through wild Internet, via wan interface.

I have Iptables with SNAT or MASQUERADE, it doesn' t matter due to  static
wan IP.
But to look at what is going on I flash that is reset Iptables ruls
completely and listen to wan interface by tcpdump.

Pre finally: routes are set up, iptables rules are flashed, neither SNAT
nor MASQUERADE is engaged.

So, when Asterisk sends out either register or option packets (or other
ones) to external VoIP IP, there is Asterisk binded (in my case INTERNAL)
IP as source IP at such outgoig packet and regarding routes rules as its
destination is anywhere in the galaxy (not within the server) , server
sends out it via wan.

That is: source = lan IP, destination = VoIP IP, port = 5060, via = wan
interface.

As SNAT is deactivated, source INTERNAL IP is not rewritten.When I set up
Iptables rules, with SNAT, of course, source internal IP is changed to
external wan IP. All work fine.

But when I make nslookup (of external name, for example gmail.com) from the
server that is Bind request external DNS, I see the following picture -
source IP at the packet is wan IP, not binded interface IP (lan IP) :

That is: source = wan IP, destination = specifid DNS IP, port = 53, via =
wan interface
I remember, there are NOT iptables rules !

>From all of this, includeing Asterisk behavior, I make a conclusion, that
source IP is choosen initially by application, not defined by routes or
iptables rules.
May be I am wrong. But there are facts what I can see.
And when I rebind Asterisk to wan interface, I see outgoing packest to
external VoIP IP via wan interface but with wan IP as a sources.

And my question was how and what setting is set up at Bind to place BINDED
interface IP as source IP at sent packets to external DNSes ?




пт, 18 окт. 2019 г. в 06:53, Grant Taylor via bind-users <
bind-users at lists.isc.org>:

> On 10/17/19 3:16 PM, CpServiceSPb . wrote:
> > But when Bind9 forwards queries to external servers, it do it via wan
> > interface but uses at the first onset server external IP as sources,
>
> I'm not surprised by this.
>
> > which is not changed by SNAT or MASQUERADE Iptables.
>
> It can be, but it depends on your iptables rules.
>
> > So how is to change Bind9 , what and where is to set up and waht setting
> > that Bind9 would send forwarding packet via wan interface but would use
> > address what it is binded to or internal, if it is binded to 127.0.0.1
> > and 192.168.0.1 ?
>
> To me, this is not a BIND setting.  Rather I think it is a Linux routing
> setting.
>
> Run the following command and check the results.
>
>     ip route get $RemoteDNSIP
>
> You will quite likely see that Linux is going to send traffic via the
> configured router using the WAN IP as the source IP address.
>
> This is functionally what BIND is doing.  It's creating a UDP datagram /
> TCP segment and asking the Linux kernel to turn it into an IP packet and
> send it.
>
> You can use ip routes and ip rules to influence this process.  More
> specifically, you can tell Linux to source packets to specific
> destinations* /from/ the LAN IP.
>
> *specific destinations are usually IP addresses.  But I am quite sure
> that there are ways to match traffic to UDP and / or TCP port 53.  You
> may need ip rules or possibly to mark packets with iptables, et al.
>
> The only time that I've seen this be a problem is when something like a
> VPN or strict filtering on the far end is in place such that the WAN IP
> is not allowed / is not able to communicate with the remote server.
> Yet, the LAN IP is.
>
> Cause Linux to use the LAN IP as the source for this specific traffic.
>
>
>
> --
> Grant. . . .
> unix || die
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20191018/3824e56c/attachment.htm>