I am stuck on an NAT for an incoming connection. On a command like
static (outside, inside) interface 192.168.1.3 netmask 255.255.255.255
[outside is the name of the outside interface to the DMZ,
inside is the name of the inside interface,
192.168.1.3 is the IP of the pinging computer from the DMZ to inside (on port TCP 20050)]
Nothing pass through to the inside side. The syslog messages I recieve during the attempt are
"build local-host outside: 192.168.1.3
build static translation from outside: 192.168.1.3 to inside 192.168.2.1
no translation group found found for tcp src outside 192.168.1.3/20050 dst inside 192.168.2.3/20050"
Has anyone any idea of what I should correct?
If the host is on the DMZ then should the static statement not read
static (dmzint, inside) interface 192.168.1.3 netmask 255.255.255.255
note: dmzint should be substituted with whatever your DMZ interface is called.
"outside" is the name I gave to the "dmzint" interface (there's only two interface on the 501: one "in", one "out" ).
Thank you for your support Ion,
If you have any other idea, don't hesitate.
I'll attach the complete pix config to clarify the situation.
Reconfigure your static to as follows and test.
static (inside, outside) interface 192.168.1.3 netmask 255.255.255.255
It looks to make it!
Thank you very much Sundar.
(I still have no connection and a "pix-2-106001: inbound TCP connection denied from 192.168.1.3/1129 to 192.168.2.3/1130 flags SYN on interface outside" syslog message instead, but I look to be a big step further).
That's good :-)
Can you resequence the access list named 'outworldACL' to as follows. The network in the object group RFC1918 denies the traffic from the outside host before the explicit permit for the host comes into effect.
access-list outworldACL permit tcp host 192.168.1.1 eq www any
access-list outworldACL permit icmp any any log
access-list outworldACL permit ip host 192.168.1.3 any
access-list outworldACL deny ip object-group RFC1918 any
There's a good and a bad news:
The good news is: you are correct about the ACL, I did mix up there just before the test with the static NATcommand suggestion # static (inside, outside) interface 192.168.1.3 netmask 255.255.255.255 #, and that was indeed the cause of the result.
The bad new is : now it appears that the static NATcommand suggestion doesn't help:
The packet still doesn't come from the DMZ,
the syslog message is still "pix-3-305006: portmap translation creation failed for tcp src inside: 192.168.2.3/1845 dst outside: 192.168.1.1/80"
+ now I lost connectivity from inside to the dmz, with a syslog like : [pix-3-305006: portmap translation creation failed for tcp src inside: 192.168.2.3/1845 dst outside: 192.168.1.1/80]
==> The experimentation was interesting, but at least that part of the command # static (outside, inside) interface 192.168.1.3 netmask 255.255.255.255 # looks ok.
Do you have any idea of what else could be failing?
If 192.168.2.3 is inside it would actually be...
static (inside, outside) interface 192.168.2.3 netmask 255.255.255.255
access-list outworldACL permit tcp host 192.168.1.2 eq 20050
Am I reading this wrong?
Well typing your suggestion, the syslog shows: # pix-6-305009: "Built static translation from inside: 192.168.2.3 to outside 192.168.1.2#
The aim is to build a static nat to allow the outside ip 192.168.1.3 to reach the 192.168.2.3 ip computer.
I had a nice looking log # build static translation from outside: 192.168.1.3 to inside 192.168.2.1# (192.168.2.1 is the ip of the pix inside interface) with the
" static (outside, inside) interface 192.168.1.3 netmask 255.255.255.255"
but indeed still the annoying #no translation group found found for tcp src outside 192.168.1.3/20050 dst inside 192.168.2.3/20050# and no packet passing through the nat from outside.
But thank you for your contribution.
From a test computer 192.168.1.3 outside (on the DMZ) I want to ping 192.168.2.3: another test computer inside.
Yes, I understand you want to ping 192.168.2.3 but to do that from the outside you must exempt 192.168.2.3 from nat.
static (inside,outside) 192.168.2.3 192.168.2.3 netmask 255.255.255.255
access-list nat0 permit ip host 192.168.2.3 host 192.168.1.3
nat (inside) 0 access-list nat0
What I was asking above is if you wanted to ping 192.168.2.3 by that address or did you want to ping 192.168.2.3 using the outside interface address of the pix?
Ok, I'll describe the network.
On the outside interface of the pix (the DMZ), the network is 192.168.1.0/24, on the inside the network is 192.168.2.0/24.
I ping from 192.168.1.3 (outside) to 192.168.2.3 (inside). Using whatever working ip for the translation (but who have by consequence to belong to 192.168.2.0/24)
So for now the situation is this:
the command static (outside, inside) interface 192.168.1.3 netmask 255.255.255.255
should work and should be the same than static (outside, inside) 192.168.2.1 192.168.1.3 netmask 255.255.255.255
When I send data from 192.168.1.3 (outside) to 192.168.2.3
the log I recieve are indeed
pix-6-609001: Built local-host outside: 192.168.1.3
pix-6-609009: Built static translation from outside 192.168.1.3 to inside 192.168.2.1
...then what I wich not to see...
Pix-3-305005: No translation group found for udp src outside: 192.168.1.3/443 dst inside 192.168.2.3
Ok so the outside source translation is successful, but do you have a static in place for the inside destination address 192.168.2.3?
Like this: static (inside, outside) 192.168.2.3 192.168.2.3 netmask 255.255.255.255
That's a good idea for a for a further step thanks.
But don't worry, I am waiting with an Ethereal on promiscuous mode on both side of the pix and it's not on the way back that my packets are blocked.
In fact nothing pass through from outside to inside. (Well, except the Xlates initiated on the inside interface).
I have to add than a "show xlate debug" command show the translation
1 in use, 7 most used
Flags: D - DNS, d - dump, I - identity, i - inside, n - no random,
o - outside, r - portmap, s - static
NAT from outside:192.168.1.3 to inside:192.168.2.1 flags s idle 0:00:06 timeout
with the idle timer updated on every attempt.
SO looks like the packets are translated but don't go out of the pix.
BUT I don't see a problematic ACL neither do I receive log from ACL blocked packet.
+ why then these log 3-305005: No translation ground found for ..."my packets"
Well, I repeat that you _must_ define a static for the destination address or network, not just the source. I did not see that in your config. Perhaps you can attached your new config?
Well Mattia, indeed that was the line which makes it work. I have to understand a bit further about the process, but indeed even to allow a simple a packet to pass through the pix from out to in, a translation from the destination address inside to that same address outside looks to be required.
Thank you very much for your help, I don't think I would have make it without you!