"Seth" <> wrote in message
news:CJqdnWzYe_dHAKLcRVn-...
> Thanks again. Hopefully, we'll be able to turn mailguard off soon. But
> just
> to clarify, is PMTU still not an issue with this config?
I can't imagine that it would be. Since I am assuming inside interface mtu
is equal to the outside int mtu, and equal to the mtu on the interface of
the server itself, there should not be an icmp "packet too big" issued by
you anyway. In the case of an outbound session, I think the pix asa would
be intelligent enough to handle it. On an inbound session if there was a
smaller mtu on the inside, I think you would still issue the correct icmp
packet but it would come from the outside interface. This is typical
anyway. I know that breaking of pmtud can wreak havoc (I have war stories,
and learned the hard way), but I don't think you will have any issues in
this case.
>
>
> "PES" <NO*SPAMpestewartREMOVE**SUCK S> wrote in
> message
> news:413f9abd$...
>>
>> "Seth" <> wrote in message
>> news:tuWdnZxpupuLBaLcRVn-...
>> > If someone pings the server, they do not get a reply even though the
>> > ACL
>> > allows for echo replies. I'f I change the static from:
>> >
>>
>> I see what you are saying now. I was looking at echo replies as a
> response
>> to echo's sent from the server.
>>
>> > static (dmz1,outside) tcp 192.168.100.147 25 10.168.100.147 366 netmask
>> > 255.255.255.255 0 0
>> > to:
>> > static (dmz1,outside) 192.168.100.147 10.168.100.147 netmask
>> > 255.255.255.255
>> > 0 0
>> >
>> > then the replies are returned, however, if I change the static, then
> port
>> > 25
>> > is no longer redirected to 366, so then I run into mailguard, which I'm
>> > trying to circumvent. turing off mailguard is not an option at this
> point.
>> >
>> > Seth
>> >
>>
>> Personally, I don't use mail guard. I don't have an answer. I no that it
> is
>> of no value now, but I'll bet pix os 7 supports esmtp. The only way that
> I
>> know that you could return pings and do this redirect would be to do the
>> redirect on the outside interface of the pix. Then enable icmp on that
>> interface. You aren't returning the pings from the server though. You
>> would just be faking it.
>>
>> > "PES" <NO*SPAMpestewartREMOVE**SUCK S> wrote in
>> > message
>> > news:413f9542$...
>> >>
>> >> "Seth" <> wrote in message
>> >> news:m-qdnfAIbptNEqLcRVn-...
>> >> > Thanks for your reply. If I wanted to allow echo replies to be
>> >> > returned,
>> >> > would I be SOL with this config, or is there something else I can
>> >> > do?
>> >> >
>> >> > Seth
>> >>
>> >> Why? Your nat specifies that your address for 10.168.100.147 would be
>> >> translated to the pat address of 192.168.100.147. You would have to
>> > permit
>> >> the echo replies to return via an acl. I've not set this up in a lab
>> >> personally, but my understanding of the pix ASA is that this would
>> >> work
>> >> fine.
>> >>
>> >> >
>> >> >
>> >> > "PES" <NO*SPAMpestewartREMOVE**SUCK S> wrote in
>> >> > message
>> >> > news:413f7e24$...
>> >> >>
>> >> >> "Seth" <> wrote in message
>> >> >> news: m...
>> >> >> > Hi,
>> >> >> >
>> >> >> > I would appreciate any help that you can provide to a problem
>> >> >> > that
>> >> >> > we're having. Our firewall has mailguard enabled, but one of the
>> >> >> > mail
>> >> >> > servers that I have running on a host needs to run ESMTP, so we
>> >> >> > translated port 25 to 366 and we were able to circumvent
> mailguard.
>> >> >> > The problem that I see now is ICMP traffic is not allowed to the
>> >> >> > server even though the ACL allows it. With ICMP being block, PMTU
>> >> >> > cannot function. Is there a way to allow ICMP traffic to the
>> >> >> > host,
>> >> >> > while still redirecting port 35 to 366? We're running 6.3(3) -
> below
>> >> >> > is the static, nat, and global associated with the host in
> question.
>> >> >> > Again, I appreciate any help that you can provide.
>> >> >> >
>> >> >> > Seth
>> >> >> >
>> >> >> > static (dmz1,outside) tcp 192.168.100.147 25 10.168.100.147 366
>> >> >> > netmask 255.255.255.255 0 0
>> >> >> >
>> >> >> > nat (dmz1) 8 10.168.100.147 255.255.255.255 0 0
>> >> >> > global (outside) 8 192.168.100.147
>> >> >>
>> >> >> The only reason you would need pmtud to work for inbound email in
> this
>> >> >> fashion would be if your mtu on the dmz is less than that on
> outside.
>> > I
>> >> >> seriously doubt that this is the case. For outbound, this
>> >> >> shouldn't
>> >> >> be
>> >> > any
>> >> >> different then any pat'd solution.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>
|
Similar Threads
