Beaker as David Tennant? Awesome.
Ran into this bug the other day, trying to point some FTP ports at a PBX on a client-site (because VPN's are 'teh complicated' and in cahoots with the devil according to some people it would seem).
https://tools.cisco.com/bugsearch/bug/CSCuc55719
The config works perfectly, right up until you specify a port-range in your service-group. Once you have a range, the source-port range is ignored, and only passes if source and destination ports are in the specified destination range.
Explicitly setting your source range of 1-65535 (or 0-65535 for UDP respectively) instead of riding on the default ranges of any wouldn't do the trick either. The implicit deny would always get in the way.
Observe!
ciscoasa# packet-tracer input outside tcp 4.4.4.4 12345 8.8.8.8 21
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 8.8.8.8 255.255.255.255 identity
Phase: 2
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Phase: 3
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: NP Identity Ifc
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
But, put source and destination ports both within the specified range, and...
ciscoasa# sh run | beg obj-pbx-tcp
object service obj-pbx-tcp
service tcp destination range ftp-data ftp
!
<trimmed>
ciscoasa# packet-tracer input outside tcp 4.4.4.4 21 8.8.8.8 21
Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (outside,voice) source static any any destination static interface host-strata-cix service obj-pbx-tcp obj-pbx-tcp unidirectional
Additional Information:
NAT divert to egress interface voice
Untranslate 8.8.8.8/21 to 192.168.2.253/21
Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside_access_in in interface outside
access-list outside_access_in extended permit tcp any object-group tcp-source-any any object-group DM_INLINE_TCP_2 log
object-group service tcp-source-any tcp
port-object range 1 65535
object-group service DM_INLINE_TCP_2 tcp
port-object eq ftp
port-object eq ftp-data
Additional Information:
Phase: 3
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (outside,voice) source static any any destination static interface host-strata-cix service obj-pbx-tcp obj-pbx-tcp unidirectional
Additional Information:
Static translate 4.4.4.4/21 to 4.4.4.4/21
<trimmed>
Phase: 7
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group voice_access_out out interface voice
access-list voice_access_out extended permit ip any 192.168.2.0 255.255.255.0
Additional Information:
Phase: 8
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (outside,voice) source static any any destination static interface host-strata-cix service obj-pbx-tcp obj-pbx-tcp unidirectional
Additional Information:
<trimmed>
Phase: 11
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 36559, packet dispatched to next module
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: voice
output-status: up
output-line-status: up
Action: allow
Ah, the joys of not paying for SmartNET.
Fortunately, as the bug tracker reports, it was fixed. Tests fine with 9.1.3.
She doesn't look anything like she sounds. Perhaps my mind just expects all asian-looking types to sound Japanese. My mind is pretty screwed up though, so who the hell knows.
