Hi,
I am still using PIX firewall; please help to fix the following
scenario:

1. Two domains with two public IP addresess.
2. Two email hardware hold each public domain and public DNS records,
    so they can communicate each other easily if nothing special.
3. But for my case, these two email hardware are behind a PIX 506E, I
have to NAT them
    for protection and  for internal user.
4. They can not communicate each other.

From the log, I found from each server, my telnet session just goes
out and no return, how can I configure the PIX506E in order to know to
let them communicate each other ?

THX a lot

On 2011-12-14 04:20:04 -0700, bensonlei@yahoo.com.hk said:

> Hi,
> I am still using PIX firewall; please help to fix the following
> scenario:
> 
> 1. Two domains with two public IP addresess.
> 2. Two email hardware hold each public domain and public DNS records,
>     so they can communicate each other easily if nothing special.
> 3. But for my case, these two email hardware are behind a PIX 506E, I
> have to NAT them
>     for protection and  for internal user.
> 4. They can not communicate each other.
> 
> From the log, I found from each server, my telnet session just goes
> out and no return, how can I configure the PIX506E in order to know to
> let them communicate each other ?
> 
> THX a lot


Just a guess here, but have you tried "no fixup smtp"?

-- 
Scott Lowe
http://blog.scottlowe.org
Replace fname and lname tokens to create valid e-mail address

On 12=A4=EB19=A4=E9, =A4W=A4=C84=AE=C959=A4=C0, Scott Lowe <fname.ln...@fna=
melname.org> wrote:
> On 2011-12-14 04:20:04 -0700, benson...@yahoo.com.hk said:
>
>
>
>
>
> > Hi,
> > I am still using PIX firewall; please help to fix the following
> > scenario:
>
> > 1. Two domains with two public IP addresess.
> > 2. Two email hardware hold each public domain and public DNS records,
> >     so they can communicate each other easily if nothing special.
> > 3. But for my case, these two email hardware are behind a PIX 506E, I
> > have to NAT them
> >     for protection and  for internal user.
> > 4. They can not communicate each other.
>
> > From the log, I found from each server, my telnet session just goes
> > out and no return, how can I configure the PIX506E in order to know to
> > let them communicate each other ?
>
> > THX a lot
>
> Just a guess here, but have you tried "no fixup smtp"?
>
> --
> Scott Lowehttp://blog.scottlowe.org
> Replace fname and lname tokens to create valid e-mail address- =C1=F4=C2=
=C3=B3Q=A4=DE=A5=CE=A4=E5=A6r -
>
> - =C5=E3=A5=DC=B3Q=A4=DE=A5=CE=A4=E5=A6r -

the "no fixup smtp" is already there before the issue

"bensonlei@yahoo.com.hk" <bensonlei@yahoo.com.hk> writes:
>> > I am still using PIX firewall; please help to fix the following
>> > scenario:
>>
>> > 1. Two domains with two public IP addresess.
>> > 2. Two email hardware hold each public domain and public DNS records,
>> >     so they can communicate each other easily if nothing special.
>> > 3. But for my case, these two email hardware are behind a PIX 506E, I
>> > have to NAT them
>> >     for protection and  for internal user.
>> > 4. They can not communicate each other.


You can't really do that with a PIX. (one of the things that makes me
dislike them overall). 


If you have the two SMTP servers on different segments on different
ports on the PIX (probably doubtful on a 506E?), you may be able to
'alias' the addressing if your version of code supports it. But the
traffic has to traverse two ports on the PIX. It can't hairpin back
out the inside port. 


The suggested solution is to do this with DNS. You'd implement DNS
views, such that when the query for the DNS hostname comes from an
internal host on your network, your DNS server returns the internal IP
address of the SMTP server that you want to communicate with, such
that the workstation/server then doesn't have to traverse the
firewall, it talks directly on the inside LAN to the server. 

I suspect now-a-days, the split view is done more with separate DNS
servers, the internal one gets configured with local view addresses
for your public zones, even if they aren't authoritative for the
global internet. Then all your local hosts/servers point to the
internal DNS server that answers with the local view of data. 

Then of course, leave the global view of the DNS to answer with the
public IP address of the server, such that everybody else communicates
normally like you are now.